-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Show a list of packages installed on environment #6992
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
Conversation
Use `pip list` and `conda list` depending on the Python environment used.
@eric-wieser would this be enough for your use case? |
Looks ideal, thanks! |
My largest problem with adding debug commands like this is that they don't mean much to users most of time and will make the command output page harder to visually scan for relevant information. It's certainly helpful when you need to debug build issues however. A few options:
This change is reasonable and seems helpful to users. The discussion above is a more general one about adding more of these types of commands and planning on how to proceed without further degrading the build detail page experience. |
The output is already grouped and collapsed by command, so users can simply choose not to expand this command. |
There is still a lot of visual pollution on the output that makes it hard to scan these commands, and the commands we care about are the ones that users interact with the most: sphinx building and pip install. |
This is exactly the reason I'm asking for this command in the first place - upon switching from pip to conda (with some embedded pip dependencies), I no longer get any install output from either pip or conda. See https://readthedocs.org/projects/cocotb/builds/10935365/ for an example of my dilemma. |
I don't see too much value on adding this as an option in the yaml and enabling/disabling it per version. I think it's more useful if it's enabled by default and you can interactively hide/show it (as you propose in the following points. You usually wants to debug something that already failed.
I'd also vote 👍 for this implementation. I really like this idea.
👍 on this as well. @agjohnson All the points mentioned are really good improvements towards a general solution and I like that --In fact, we should create 2 separate issues to track them. However, I don't think we should block this PR on on design decision at this point (or waiting on them to be implemented). This PR is already using a feature flag to enable this package listing command in a per-project way. So, it should be harmless for most of users and useful for the ones who needs this behavior currently. |
Yup, agreed. I think this PR can continue. The next step is already handled on the template project, removal of the path from the command line. This makes it far easier to scan the output lines for what you're looking for. Whether we take on the engineering time of a |
Cool! I created two different issues to track those points. I'm removing design decision from this PR so we can continue with the review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is useful. I'd love to see it as part of the normal build to make it more obvious whats installed for users in one place, but this is good for now 👍
@eric-wieser Hi! I enabled this flag in your project. Let me know if it does work as you expected. |
Thanks, it shows everything I needed to see:
|
Awesome! Thanks for reporting back |
Use
pip list
andconda list
depending on the Python environment used.I went ahead and propose an implementation for this since it was requested again at #6989 (comment) . So, worth re-consider to add it.
Edit: this behavior is under a feature flag.
Virtualenv
Conda