-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Evolving the pip list json output #11223
Comments
I don’t like Introduing |
in my opinion, |
Regarding incompatible changes to the JSON format, I'd prefer But equally, I would say that adding environment data doesn't really fit the remit of |
The reason I would like to add An important interface is querying what is installed. Now, to further analyze the metadata in the context of the target environment, and in particular to process |
Sorry, what I meant was that I'd like a Anyway, this is separate from the question of "evolving the pip list json output". My view on that is:
If having to call pip multiple times to get the information that tools need is too costly, maybe the information gathering code should be broken out into a standalone library which can be called from the sorts of tool you're imagining, and pip can vendor that library. In all honesty, I think that's the best way forward in general - we really should be pushing as much functionality as we possibly can into reusable libraries, rather than locking people into calling pip as a CLI. |
Can you elaborate what you have in mind in terms of additional data ?
You can see it in the example provided in #10771.
Agreed, and in this case, the library exists (packaging) and using it to get environment information is a one liner as illustrated in #10771.
The problem with libraries for environment management tools is that, if the library and the tool need to be installed in the target environment to function, then it risks version conflicts, where we rather want such tools to not perturbate the environment they manage with their own dependencies. So for such cases, relying on pip (that is quite ubiquitous in python environments) to do obtain the information via CLI makes a lot of sense. About That said I agree that returning an array makes sense for pip list and I'm also not comfortable with doing a backward incompatible change. On the other hand, adding a new command that does almost the same as pip list sounds overkill. Maybe that's why I was initially leaning towards an option to request for a variant json format. |
No, I don't have anything in mind, simply that I don't think that just the environment data is sufficient to justify a whole new pip subcommand. But I do appreciate that saying on the one hand that environment data should be in a separate command but then saying that it's not enough to justify a separate command is not very helpful. My logic is basically: OK. Having that data in
Well, not really. I have a long-term hope that we can move to a situation where we can do Sure, right now, pip is present in most environments. And relying on that is a practical solution for now. But it's not guaranteed to remain that way, and we shouldn't encourage people to think that it is.
Given that it's literally nothing more than a call to packaging,
is just as good. And if you want to assume nothing but pip, import from Overall, I think the idea of adding pip output options in support of "environment management" tools is probably something that should wait a little, and ideally be driven by specific problems encountered by actual tools. Trying to solve what feel like hypothetical (at this point in time) use cases is likely to end up with a design that satisfies no-one. |
I hope we reach that goal one day too.
IMO these are not hypothetical at all. I drive everything I do from concrete use cases such as this one. And after all, most such tools currently hack, patch or rip off pip in one way or another, so I personally believe that exposing some of the pip logic through a couple of cli+json is a good and pragmatic way to help the ecosystem implement correct solutions without hacking the wheel over and over. Especially when the maintenance cost for pip is low. And this is not in opposition with creating libraries as these solve use cases where libraries are not applicable or impractical. Anyway, I'll let this rest for a while now. Thanks for your input, as always. |
Actually, it occurred to me that we may even be able to do this right now. I put together a very simple proof of concept and it seems to work. If you put the following script alongside a "lib" directory with pip installed into it (
I don't think it would take much to turn this into a viable "standalone pip" application (I'd mostly just want to set up an executable wrapper for Windows). I've done some very basic testing - this would need a lot more real-world testing to make sure there aren't any problem edge cases, but it basically seems to work. |
Currently,
pip list --format=json
produces a json array.I think it could be valuable for pip list to output additional information, such as an
environment
object with PEP 608 environment markers, etc. Such a change would require the pip list output to evolve in a backward incompatible way, in this case because of the current array output that would need to be converted to an object.It is to be noted that such back-ward incompatible changes will probably be very infrequent, since we'll presumably only want to add new information to the output. An example of backward compatible change is #11097 which adds a metadata property to the list items.
How should such backward-incompatible changes be addressed ?
--format=json+v2
?pip inspect
?The text was updated successfully, but these errors were encountered: