Hi Peter, On Oct 8, 2013, at 11:01 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Tue, Oct 8, 2013 at 3:47 PM, Greg Von Kuster <greg@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