Hi Peter,
On Oct 8, 2013, at 11:01 AM, Peter Cock <p.j.a.c...@googlemail.com> wrote: > On Tue, Oct 8, 2013 at 3:47 PM, Greg Von Kuster <g...@bx.psu.edu> wrote: >> Hi Peter and others, >> >> Peter wrote: >>> As an aside, I've asked before about why the function tests look >>> at *.loc rather than *.loc.sample and not had a clear answer. >> >> The functional tests look at .loc files because they will have uncommented, >> functionally correct entries. The .loc.sample files usually have commented >> "sample" entries that provide an idea to the Galaxy admin as to what should >> actually go into the associated .loc file. For example, twobit.loc.sample >> has: >> >> #droPer1 /depot/data2/galaxy/droPer1/droPer1.2bit >> #apiMel2 /depot/data2/galaxy/apiMel2/apiMel2.2bit >> #droAna1 /depot/data2/galaxy/droAna1/droAna1.2bit >> #droAna2 /depot/data2/galaxy/droAna2/droAna2.2bit >> >> while twobit.loc has: >> >> droPer1 /depot/data2/galaxy/droPer1/droPer1.2bit >> apiMel2 /depot/data2/galaxy/apiMel2/apiMel2.2bit >> droAna1 /depot/data2/galaxy/droAna1/droAna1.2bit >> droAna2 /depot/data2/galaxy/droAna2/droAna2.2bit > > It depends on the tool, some example.loc.sample files already > contain real working entries. In this case if it would be useful > for the twobit unit tests, why not provide twobit.loc with the > uncommented lines? The .loc files are looked at because the .loc.sample files are not required to have uncommented unctional entries (although some obviously may have them). > > (Either way the Galaxy Admin will have to edit twobit.loc > to suit the local setup anyway.) Yes > >>> As soon as the local administrator edits the provided default *.loc >>> files, this could break functional tests using the *.loc.sample >>> values. >> >> The intent is that the local administrator manually edits the .loc file to >> include the functionally correct entries based on entries in the .loc.sample >> file. >> >>> The simple fix is for the test framework to preferentially >>> load the *.loc.sample file if present: >>> >>> http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-April/014370.html >>> http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-August/016159.html >> >> >> I don't agree with this - the sample files should be used as guidance for >> the admin to create functionally correct .loc files. This is the same >> aopproach used for all Galaxy .sample files ( e.g., universe_wsgi.ini.sample >> <-> universe_wsgi.ini, etc ) > > Why then does the tool_conf.xml.sample file get used by the > test framework then? This is a clear example of *.xml.sample > being used in the test framework over the 'real' file *.xml. > > I really don't understand this design choice - I would use > tool_conf.xml (it lists the tools actually installed on our Galaxy, > and therefore the things worth testing) while by default > tool_conf.xml.sample includes a whole load of things where > the binaries etc are missing and so the tests will fail (hiding > potential real failures in the noise). I'm not quite sure of the reason for htis as I didn't make this design choice - I'm sure "ancient Galaxy history" plays a role in this decision. > > The quick fix is to edit tool_conf.xml.sample but that can > cause trouble with hg and system updates. > > (I appreciate as more and more tools leave the core framework > and migrate to the tool shed this is less important, Yes, this is true. > > -- > > Perhaps rather than overloading *.loc.sample with two roles > (sample configuration/documentation and unit tests), we > need to introduce *.loc.test for functional testing purposes? I'm hoping we don''t have to go this route as we have so many priorities. If you would like this implemented though, please add a new Trello card and we'll consider it. > > That still leaves open the question of how best to install > the test databases or files that the *.loc.test file would > point at for running functional tests. Yes! > > Thanks, > > Peter ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
