-
Notifications
You must be signed in to change notification settings - Fork 11
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
Add pip listing method #36
Conversation
Just for clarification, how does that differ from a |
E.g., the dummy package |
Maybe the whole version-finding stuff we have could be replaced with grepping the |
Exactly - I often work in cluttered, experimental environments and don't need to share the versions of everything for a given project.
That's a really interesting find... we should take a look in that source to see how they implemented it.
That might be a nice approach to implement Does that work for packages installed with anaconda as well? |
Yes it does work for |
Instead of making the user write
couldn't you implement that directly in
so if So the user would only have to do
to write |
I do use |
I think everything is addressed now. @prisae can you approve whenever you get a chance? |
One incredibly annoying thing to consider - many packages out there have PyPI names that vary from their import statement, e.g. |
I do not think this as an issue, because the reporting always works with the name as you would import it. You can even provide strings or packages itself. E.g.
So there should be no confusion, IMHO. I usually use packages, not strings, because I am interested in the things I actually imported, so directly provided them works just fine. Maybe there are other scenarios which might differ. |
I'm only referring to how it will be an issue for this PR when we send those packages to a |
Now I get you. Correct. In this case we would have to implement the |
I'm going to put this on hold for a while and see if anything comes of #37 |
This adds a way to create
pip
requirements files addressing part of #35