Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[17.01] Fix order of PATH when doing hacky Conda activating. #3620

Closed

Conversation

jmchilton
Copy link
Member

Thanks to @yhoogstrate's comment here fe2a1d8#commitcomment-20900607.

@@ -325,7 +325,7 @@ def shell_commands(self, requirement):
# On explicit testing the only such requirement I am aware of is samtools - and it seems to work
# fine with just appending the PATH as done below. Other tools may require additional
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/appending/prepending/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebased with this fix, thanks!

@mvdbeek
Copy link
Member

mvdbeek commented Feb 17, 2017

I'm not crazy about this change. IUC shouldn't be putting samtools in the global PATH in such a hacky way as we do currently. If a python binary happens to be in the samtools environment (admittedly that shouldn't happen), we're back to square one. I think the proper fix is to install samtools into __samtools@uv in the travis recipe.

@jmchilton
Copy link
Member Author

Regardless of how the IUC should configure its testing - don't you think binaries from "required" Conda recipes should take precedent over generic background ones that might not even be setup for Galaxy - let alone that particular requirement?

@mvdbeek
Copy link
Member

mvdbeek commented Feb 17, 2017

But this only happens for tools that are marked to preserve the python environment. So in fact this already happens?!

@mvdbeek
Copy link
Member

mvdbeek commented Feb 17, 2017

See also fe2a1d8#commitcomment-20931952.
I think my first comment is slightly besides the point. I think the whole preserve python environment thing is there to make an exception and keep python off the PATH. So i think it should come last.

@mvdbeek
Copy link
Member

mvdbeek commented Feb 17, 2017

So the tool in question is SAM-to-BAM, which happens to be on the preserve python list. But the current version doesn't need an importable galaxy ... I'm OK to merge this, and then we can augment the mechanism to take into account the version as well.

@jmchilton
Copy link
Member Author

I think the whole preserve python environment thing is there to make an exception and keep python off the PATH. So i think it should come last.

That actually makes sense to me - now I see.

The better fix here is to apply that hack only to older versions of the tool - that logic needs to be added anyway.

I'm leaning away from merging this PR.

@jmchilton jmchilton closed this Feb 17, 2017
jmchilton added a commit to jmchilton/galaxy that referenced this pull request Feb 17, 2017
This is a less broken alternative to galaxyproject#3620 and something I intended to ultimately do anyway.

sam-to-bam used to be broken but now it isn't, we need to express that. Ideally we would move most of the things from the unversioned list to the versioned list as they are fixed.

xref galaxyproject#3620 (comment)
xref galaxyproject@fe2a1d8#commitcomment-20900607
xref galaxyproject#3351
xref galaxyproject/tools-iuc#1148
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants