Avoid at sign in conda env directory names

[peterjc]

The current conda environment naming can break Perl scripts within conda packages:

Global symbol "@_uv_" requires explicit package name (did you forget to declare "my @_uv_"?)

e.g. https://travis-ci.org/peterjc/kodoja_galaxy/jobs/339418927 with a tool tested against Galaxy's master branch:

|  Possible unintended interpolation of @_uv_ in string at /home/travis/miniconda3/envs/__kodoja@_uv_/bin/kraken line 28.
|  Global symbol "@_uv_" requires explicit package name (did you forget to declare "my @_uv_"?) at /home/travis/miniconda3/envs/__kodoja@_uv_/bin/kraken line 28.
|  BEGIN not safe after errors--compilation aborted at /home/travis/miniconda3/envs/__kodoja@_uv_/bin/kraken line 32.
|  Traceback (most recent call last):
|  File "/home/travis/miniconda3/envs/__kodoja@_uv_/bin/kodoja_search.py", line 115, in <module>
|  quick_minhits=args.kraken_quick, preload=args.kraken_preload)
|  File "/home/travis/miniconda3/envs/__kodoja@_uv_/bin/diagnostic_modules.py", line 203, in kraken_classify
|  subprocess.check_call(kraken_command, shell=True)
|  File "/home/travis/miniconda3/envs/__kodoja@_uv_/lib/python3.6/subprocess.py", line 291, in check_call
|  raise CalledProcessError(retcode, cmd)
|  subprocess.CalledProcessError: Command 'kraken --threads 1 --db /home/travis/build/peterjc/kodoja_galaxy/test-data/krakenDB_test/ --fastq-input ./trimmed_read1 > ./kraken_table.txt' returned non-zero exit status 255.

Versus the same test on by conda_env_at_sign branch (from dev so there are other differences), where this works (but then breaks in panda later on): https://travis-ci.org/peterjc/kodoja_galaxy/jobs/339418928

---

I could reproduce this locally, and "fix" this by editing the installed Kraken package by editing /home/pc40583/miniconda3/envs/__kodoja@_uv_/bin/kraken* to replace lines:

my $KRAKEN_DIR = "/home/xxx/miniconda3/envs/__kodoja@_uv_/libexec";

with:

my $KRAKEN_DIR = '/home/xxx/miniconda3/envs/__kodoja@_uv_/libexec';

i.e. Edit all the Perl scripts declared with the metadata has_prefix_files in the Kraken package's meta.yaml https://github.com/bioconda/bioconda-recipes/blob/master/recipes/kraken/meta.yaml

Looking over the conda stack, I think https://github.com/conda/conda/blob/master/conda/core/portability.py does the prefix editing as per the metadata entries, but this does not alter the quote marks.

The double quotes appear in the source, see https://github.com/DerrickWood/kraken/blob/v1.0/scripts/kraken#L28 and indeed v1.1 as well,

my $KRAKEN_DIR = "#####=KRAKEN_DIR=#####";

This marker gets replaced by install_kraken.sh in a manual installation, as used in the bioconda recipe. I think we can do the quote fix as part of the recipe's existing for loop in https://github.com/bioconda/bioconda-recipes/blob/master/recipes/kraken/build.sh

However - While we could fix the Kraken recipe and others one by one, I think it would be safer to avoid the problematic @ sign in Galaxy's environment naming.

[mvdbeek]

Hmm, I think we should also maintain compatibility with existing environments here, so we should allow falling back to @ somehow.

[mvdbeek]

@galaxybot test this

[peterjc]

I know hardly anything about how these directories are used, and the implications of this change on an already up-and-running Galaxy instance. My testing has all been on new installs only.

[jmchilton]

Thanks for the detailed issue report and fix @peterjc! First - I apologize for sticking an @ in there, seems that was a huge mistake on my part.

That said - we have so many packages and such that depend on these paths at this point and it does seem like an actual bug in the underlying packages if they cannot be installed on these paths. So I think it would be better to fix these packages in bioconda one at a time as they come up for now - to avoid the complexity and slow down of having to search multiple different paths in Galaxy (for older installs vs new installs).

But I'm not -1 at all on this, especially if @mvdbeek thinks it is a good idea to just add backward compatibility checks and go with this change - then I'll jump on board. I'm just going to mark this PR as WIP for now until backward compatibility is restored.

[peterjc]

Given there are backwards compatibility issues, I think that's sensible.