Switch to pip python API?

[aelgru]

On some Linux distributions (namely fedora) pip comes as pip-python instead of pip. see fedora

[mriehl]

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).

[aelgru]

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

[mriehl]

I mean these features would be accessible with the api. The command-line is
kinda limited.
On 21 Nov 2013 22:24, "Michael Gruber" notifications@github.com 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
.

[mriehl]

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

[mriehl]

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.

[aelgru]

This ...

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

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

[mriehl]

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!

[mriehl]

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?

[aelgru]

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 ...

[mriehl]

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.

[aelgru]

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