Switch to pip python API? about pybuilder HOT 11 CLOSED

Apparently in 2010 pip was garbage from an API perspective.
Not sure if it has changed.

https://groups.google.com/forum/m/#!topic/python-virtualenv/_VmM-R1Y8pg

We could add some cool features though like idempotency (don't install if
dependency is there and the upgrade option is disabled, etc).

from pybuilder.

Yes, we could add some new features, but this won't change the fact that 'pip' would not be executed on fedora since it is called 'pip-python' there ...

The API is not awesome, but managable:
https://github.com/pypa/pip/tree/develop/pip/commands

from pybuilder.

I mean these features would be accessible with the api. The command-line is
kinda limited.
On 21 Nov 2013 22:24, "Michael Gruber" [email protected] wrote:

Yes, we could add some new features, but this won't change the fact that
'pip' would not be executed on fedora since it is called 'pip-python' there
...

The API is not awesome, but managable:
https://github.com/pypa/pip/tree/develop/pip/commands

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-29025841
.

from pybuilder.

Why is this labeled as a bug? Because it's broken on fedora?

from pybuilder.

Is it acceptable if we just scan PATH to decide whether to use pip-python or pip?
I just played around with the pip "API" and the InstallCommand wants an option parser as argument. I am not working with that kind of API.

from pybuilder.

This ...

import pip
pip.main(['install', 'committer'])

... works for me. What do you think about that?

from pybuilder.

Haha, ok. Yeah that works for me too. I think it's a bit ridiculous to call the command line entrypoint an "API" but due to the awesome separation of concerns (cough cough) the commands are all aware of the option parser anyway, so...

I guess that settles it, I'll implement this tomorrow. Thank you for your guidance!

from pybuilder.

Hi @aelgru , can you have a look at my branch? I ask for a review because I'm not overly happy with how it turned out. We need to prevent pip from cluttering up stdout/stderr (imho the contextmanager is the least ugly solution to this) and we need to deal with a possible SystemExit or whatever pip throws at us.

I haven't done any refactoring yet (the return codes are a good candidate for instance) because I don't want to do any superfluous work. Do you agree with the solution or should we look into something else like determining the adequate pip script name?

from pybuilder.

This is so annoying... 😠 ... looks like we have to write our own package installer.

My problem with the script solution: I guess the people who renamed pip to pip-python on Fedora systems had their reasons for doing that. There might be something else already called pip. Detecting the right executable might not be straight forward too.

Using the "not existing API" of pip by calling the script entry point pip.main might end up in an disaster too since there is no guarantee the this does not change ... since it is not an API.

What about checking

import platform
platform.linux_distribution()

?

If we are on a Fedora system we set the name of the script to pip-python ...

from pybuilder.

I don't like handling extra cases like that. It usually ends with a clusterf***.

For instance look at https://bugzilla.redhat.com/show_bug.cgi?id=958377 .
Starting with fedora 17, it's pip instead of pip-python again. So we have to check for fedora + for the fedora version, and decide from there.

from pybuilder.

Let's accept we learned a lot about pip and Fedora and close the issue. I am sorry for creating this issue at all.

from pybuilder.