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?

(Either way the Galaxy Admin will have to edit twobit.loc
to suit the local setup anyway.)

>> 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).

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,


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?

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.


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:

To search Galaxy mailing lists use the unified search at:

Reply via email to