Hi Galaxy team, As my local instance grows it becomes more difficult each time to upgrade. I now use diff on the various config files to see what changes I should lift over to the new install. (I don't update, but leave my current setup untouched as a backup, create a new install and if that works switch to the new setup using a symlink.) Would it be possible to use a special directory with config files for site specific customizations? I'm thinking of something like Apache's "conf.d" directory or good ol' SRS's "sites" directory. This would allow us to leave the original Galaxy tools + datatypes config files untouched and list our local additions/mods in separate config files making upgrades a bit easier... Cheers, Pi --------------------------------------------------------------- Biomolecular Mass Spectrometry & Proteomics group Utrecht University Visiting address: H.R. Kruyt building room O607 Padualaan 8 3584 CH Utrecht The Netherlands Mail address: P.O. box 80.082 3508 TB Utrecht The Netherlands phone: +31 6 143 66 783 email: pieter.neerincx@gmail.com skype: pieter.online ---------------------------------------------------------------
Yes, let's figure out the best way to do this. Are you primarily concerned with tool_conf.xml and datatypes_conf.xml? We could definitely allow multiple of these to be specified, and merged together. Would that be reasonable? Definitely would like suggestions on how you see this working and what would be easiest. -- jt On Mar 16, 2010, at 6:43 PM, Pieter Neerincx wrote:
Hi Galaxy team,
As my local instance grows it becomes more difficult each time to upgrade. I now use diff on the various config files to see what changes I should lift over to the new install. (I don't update, but leave my current setup untouched as a backup, create a new install and if that works switch to the new setup using a symlink.) Would it be possible to use a special directory with config files for site specific customizations? I'm thinking of something like Apache's "conf.d" directory or good ol' SRS's "sites" directory. This would allow us to leave the original Galaxy tools + datatypes config files untouched and list our local additions/mods in separate config files making upgrades a bit easier...
Cheers,
Pi
--------------------------------------------------------------- Biomolecular Mass Spectrometry & Proteomics group Utrecht University
Visiting address: H.R. Kruyt building room O607 Padualaan 8 3584 CH Utrecht The Netherlands
Mail address: P.O. box 80.082 3508 TB Utrecht The Netherlands
phone: +31 6 143 66 783 email: pieter.neerincx@gmail.com skype: pieter.online ---------------------------------------------------------------
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
universe_wsgi.ini would also have to be there. I have lots of specific SGE settings for many tools in there. In terms of getting them working, my suggestion would be to have the 'local' tools grouped under subheadings as defined in each of the XML files. This way you'd have the common Galaxy tools on the website followed by each of your own groups of tools under different subheadings. Cheers, Chris On 16/03/10 23:05, James Taylor wrote:
Yes, let's figure out the best way to do this. Are you primarily concerned with tool_conf.xml and datatypes_conf.xml? We could definitely allow multiple of these to be specified, and merged together. Would that be reasonable? Definitely would like suggestions on how you see this working and what would be easiest.
-- jt
On Mar 16, 2010, at 6:43 PM, Pieter Neerincx wrote:
Hi Galaxy team,
As my local instance grows it becomes more difficult each time to upgrade. I now use diff on the various config files to see what changes I should lift over to the new install. (I don't update, but leave my current setup untouched as a backup, create a new install and if that works switch to the new setup using a symlink.) Would it be possible to use a special directory with config files for site specific customizations? I'm thinking of something like Apache's "conf.d" directory or good ol' SRS's "sites" directory. This would allow us to leave the original Galaxy tools + datatypes config files untouched and list our local additions/mods in separate config files making upgrades a bit easier...
Cheers,
Pi
--------------------------------------------------------------- Biomolecular Mass Spectrometry & Proteomics group Utrecht University
Visiting address: H.R. Kruyt building room O607 Padualaan 8 3584 CH Utrecht The Netherlands
Mail address: P.O. box 80.082 3508 TB Utrecht The Netherlands
phone: +31 6 143 66 783 email: pieter.neerincx@gmail.com skype: pieter.online ---------------------------------------------------------------
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
-- Dr Chris Cole Senior Bioinformatics Research Officer School of Life Sciences Research University of Dundee Dow Street Dundee DD1 5EH Scotland, UK url: http://network.nature.com/profile/drchriscole e-mail: chris@compbio.dundee.ac.uk Tel: +44 (0)1382 388 721 The University of Dundee is a registered Scottish charity, No: SC015096
Hi, I agree tool_conf.xml, datatypes_conf.xml and the *_wsgi.ini files should be there. Hence if this would work for universe_wsgi.ini, it would be nice if it would also handle reports_wsgi.ini :). As long as the additional conf files (both the ones from the original distro and customized local sites) only add info it's easy. The tricky bit would be how to handle conflicting info from multiple conf files in a conf.d directory. I don't think there is an easy solution for this apart from simply using either the first or last parsed setting and throwing a warning on startup. If I remember correctly that is more or less what Apache does... In addition to smoother updates, having a conf.d directory could make it easier for people to share and distribute tools/datatypes/toolconfigs for Galaxy. Adding support for a tool would simply mean copying the required *.conf files to the conf.d dir, which is less tricky than writing an installer that modifies a single *.conf file... Cheers, Pi On Mar 17, 2010, at 2:40 PM, Chris Cole wrote:
universe_wsgi.ini would also have to be there. I have lots of specific SGE settings for many tools in there.
In terms of getting them working, my suggestion would be to have the 'local' tools grouped under subheadings as defined in each of the XML files.
This way you'd have the common Galaxy tools on the website followed by each of your own groups of tools under different subheadings. Cheers,
Chris
On 16/03/10 23:05, James Taylor wrote:
Yes, let's figure out the best way to do this. Are you primarily concerned with tool_conf.xml and datatypes_conf.xml? We could definitely allow multiple of these to be specified, and merged together. Would that be reasonable? Definitely would like suggestions on how you see this working and what would be easiest.
-- jt
On Mar 16, 2010, at 6:43 PM, Pieter Neerincx wrote:
Hi Galaxy team,
As my local instance grows it becomes more difficult each time to upgrade. I now use diff on the various config files to see what changes I should lift over to the new install. (I don't update, but leave my current setup untouched as a backup, create a new install and if that works switch to the new setup using a symlink.) Would it be possible to use a special directory with config files for site specific customizations? I'm thinking of something like Apache's "conf.d" directory or good ol' SRS's "sites" directory. This would allow us to leave the original Galaxy tools + datatypes config files untouched and list our local additions/mods in separate config files making upgrades a bit easier...
Cheers,
Pi
--------------------------------------------------------------- Biomolecular Mass Spectrometry & Proteomics group Utrecht University
Visiting address: H.R. Kruyt building room O607 Padualaan 8 3584 CH Utrecht The Netherlands
Mail address: P.O. box 80.082 3508 TB Utrecht The Netherlands
phone: +31 6 143 66 783 email: pieter.neerincx@gmail.com skype: pieter.online ---------------------------------------------------------------
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
-- Dr Chris Cole Senior Bioinformatics Research Officer School of Life Sciences Research University of Dundee Dow Street Dundee DD1 5EH Scotland, UK
url: http://network.nature.com/profile/drchriscole e-mail: chris@compbio.dundee.ac.uk Tel: +44 (0)1382 388 721
The University of Dundee is a registered Scottish charity, No: SC015096 _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
On Wed, Mar 17, 2010 at 03:07:19PM +0100, Pieter Neerincx wrote:
Hi,
I agree tool_conf.xml, datatypes_conf.xml and the *_wsgi.ini files should be there. Hence if this would work for universe_wsgi.ini, it would be nice if it would also handle reports_wsgi.ini :). [snip]
When looking to see if we could do privilege separation at the file level on config files (want non-admin users to be able to edit portions but not others) I foudn that the paste config parser does support includes: "This way some settings could be defined in a generic configuration file (if you have use = config:other_config_file) or you can publish multiple (more specialized) applications just by adding a section. -- http://pythonpaste.org/deploy/#configuration So inside the universe_wsgi.ini one can already put a line line: use = conf:local_settings.ini to keep some settings outside of the universe_wsgi.ini file. It's possible that syntax already supports wildcards, but if not getting that patch upstream into paste ought not find too much resistance I'd hope. -- Ry4an Brase 612-626-6575 University of Minnesota Supercomputing Institute for Advanced Computational Research http://www.msi.umn.edu
Just to add one data point: What we chose to do in our installation to make upgrades easy was to utilize Mercurial's queue (mq) functionality to keep our local deltas as overlay "patches" atop galaxy-dist. Now when we want to upgrade to galaxy-dist's tip we just need to: $ hg qpop --all # undoes all of our custom changes $ hg pull -u # pulls all changes from galaxy-dist and applies them $ hg qpush --all # reapplies all our changes one by one If during that re-apply mercurial can't figure out how the old change applies to the new galaxy the merge tool is popped up and one graphically selects A or B for each differing chunk. Here are some intro resources on mq: http://video.google.com/videoplay?docid=5037120727513519915&hl=en# http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html And if you're new to mercurial entirely this great new intro site just launched: http://hginit.com/ Meanwhile, might anyone have any insight as to why we can't get histogram's working? --> http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-March/002199.html Thanks, On Wed, Mar 17, 2010 at 01:40:04PM +0000, Chris Cole wrote:
universe_wsgi.ini would also have to be there. I have lots of specific SGE settings for many tools in there.
In terms of getting them working, my suggestion would be to have the 'local' tools grouped under subheadings as defined in each of the XML files.
This way you'd have the common Galaxy tools on the website followed by each of your own groups of tools under different subheadings. Cheers,
-- Ry4an Brase 612-626-6575 University of Minnesota Supercomputing Institute for Advanced Computational Research http://www.msi.umn.edu
participants (4)
-
Chris Cole -
James Taylor -
Pieter Neerincx -
Ry4an Brase