-
Notifications
You must be signed in to change notification settings - Fork 428
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
WIP: add debug command for creating envs #3237
Conversation
46130eb
to
d6961f8
Compare
4497282
to
f56bea0
Compare
1320243
to
9601554
Compare
I haven't tested out everything yet but here are my initial notes:
Questions:
|
hmm... yes, this is a little rough. Thanks for poking at it!
Is the content of those files all the same? I think they are different.
It's a bug if any of these are the same as any other.
Good point. I'll have to think about this. I think
Sure, perhaps as additional text shown at the end. I'm definitely assuming some expert-level users here, but making the tool more friendly is never a bad thing. |
835c45a
to
ef1d3f9
Compare
Verified that
Added text like:
after the path activation command printout. |
Did a bit more testing on this:
Steps to reproduce bug:
|
This is great! I'm not sure if it's the right thing to do, but I'd probably usually want to debug with a not-long host prefix if I could (parent/_host instead of parent/_h_placehold...). I know that would technically not test the issues that the long path is needed for, but the long paths genuinely make things harder to debug. |
Thanks @minrk, that's a good idea, and should be easy to implement. I had a couple of other ideas this morning:
|
I would love this. I regularly do btw, I've already used this to work out some issues in the petsc and openmpi repos, and it helped! A couple small weirdnesses I ran into:
|
Thank you for working on this. I'll try it out in a bit. +1 to Min's comments that making builds easier for debugging (e.g. removing the long host prefix) would be best, as long as it is understood by the user that this is for creating debug builds of packages only, and not builds that should be pushed to users. |
6fe53e8
to
3950180
Compare
57850bd
to
b33991b
Compare
81a371c
to
97ed716
Compare
328c760
to
da0af41
Compare
liefldd: Check runpaths (first) as well as rpaths
2b9e7ad
to
6a44ac5
Compare
050653c
to
33df35f
Compare
afc359e
to
273561b
Compare
Going ahead with this. There's one failing test: tests/test_subpackages.py::test_subpackage_independent_hash That test passes locally. I'm not concerned about it now, though it would be nice to have green icons again... |
Thank you for implementing this! 👍 I was a little bit surprised that I still needed to run |
Hi there, thank you for your contribution! This pull request has been automatically locked because it has not had recent activity after being closed. Please open a new issue or pull request if needed. Thanks! |
The purpose of this feature is to aid in creating environments and activation scripts so that users can quickly create an environment just like conda-build creates for build/hot or test. This feature creates the envs, splits the env activation stuff into a separate script that can be sourced without running a build, and outputs a line that can be copy-pasted to get into an activated shell that works the same as a build inside conda-build.
examples:
Note that you have to have the dash between conda and debug. That's because conda has those executables hard-coded, and
conda debug
may not work until we add an entry for it in conda.fixes #1751