Install pip via the boostrap get-pip.py file

[kirkhansen]

Installing pip via apt has, historically, been flaky at best. A few months ago, I was unable to build my debian image that needed to install python packages, because the python-pip install was failing. Additionally, python-pip in apt is frequently very out of date, and this method guarantees the latest version when new images are built.

This PR removes python-pip, adds wget, and runs the bootstrap get-pip.py installer to install pip.

The url for installing pip was pulled from the official pip installation guide.

[andsens]

I have never had any issues with python-pip tbh, that doesn't mean you're not right though. I do however need a better justification than it's flakey :-)
Would you mind elaborating on the exact issues you think people encounter (or better yet, link to sources) and how using get-pip.py alleviates those issues?
@CMeza99, @mengelmann, @zmarano any opinions on this?

[drts01]

Caveat: I have not used packages from the updated pypi mirrors.

pip and the pypi repo have been flake and break things through upgrades. but I do not think changing what the distro provides should be bootstrap-vz's default behavior. I think this would be unexpected behavior. But if pip is not working with the pypi mirrors, I think this is the responsibility of the python community or the distro to resolve. I do not think bootstrap-vz should implement this workaround.

I am still using 9.0.1. because that is what works with our mirrors and repos. So I believe this is an exercise that has to be left up to the user. Anyone using bandersnatch, Artifactory, etc will have to make sure they use a compatible version of pip.

Also, pip broke importing it with v10. So this may cause more unexpected behavior for users.

[andsens]

I do think bootstrap-vz should implement this workaround.

Your message reads like a don't but that sentence says do?

[drts01]

Ha. Yes. Was trying to multitask and failed.

[zmarano]

My opinion is that you should use the packaged version from Debian and if any given user wants to install pip another way then they can do so on their own accord. Also, generally I don't think pip should be installed by default anyway.

[andsens]

Also, generally I don't think pip should be installed by default anyway.

It isn't, this is a plugin for installing pip packages :-)
Alright @kirkhansen, I'm closing this one. Seems to me there are too many arguments against doing this, especially when the users can do this themselves using the various built-in escape hatches.

[kirkhansen]

I'm still trying to find some of the source links for 'flakiness', but I think it all boiled down to too many ways of installing pip, and all of them not working well together as @CMeza99 suggests. There was also a time where building the image for EC2 failed outright due to python-pip, but those logs are lost forever it seems. FWIW, the python-pip is working for me now.

One thing that this discussion does bring to mind is that the python-pip will install pip for python2. Thoughts about having an option to pick a python version (2 or 3) and install the appropriate packages [(python-pip, python-dev), (python3-pip, python3-dev)] and eventually defaulting to python3-pip when python2 is officially unsupported? Perhaps the pip_plugin shouldn't try and install pip and just assume a pip will be there, and it's up to the user to define how it gets there?

[drts01]

I think the default should be what the default is for that release of Debian. I would be in favor for a flag/option to override it, to use python3 and/or use upstream pip.

[andsens]

Yup, agreed. An option to pick 2 or 3 would be great. I'd be open to a PR like that :-)

[kirkhansen]

Upon further reflection, it might make more sense to have a clone of the pip_install plugin (say pip3_install). I could see people needing to install both python2 packages and python3 packages. This also sets the stage for python4. How open would you be to that kind of PR, @andsens ?

[andsens]

Definitely. They are two very different beasts, handling them in two different plugins makes sense. And it's not like there's a lot of code to begin with, so DRY doesn't really apply :-)