Closed mlavin closed 7 years ago
How about if we pin pip to 8.1.1 in python/init.sls? If individual projects want to use a newer pip, they could specify it in their requirements.txt. I think that would work... the chicken/egg pieces of pip-installing-pip get me confused.
Our main reasoning for switching from using the apt-installed pip was that it got too out-of-date to properly setup the venv, but hopefully version 8.1.1 will be good enough for a long time.
On top of these changes, we'd need to document how to fix projects which were already broken by this bug (or which inadvertently get broken before upgrading to this new fixed margarita).
Does that sound reasonable?
Yes there are two versions of pip: the global version and the one inside the venv. Inside the venv, Salt doesn't care about the version. The global version matters to Salt and makes the most difference when bootstrapping the initial venv (or rebuilding it).
On top of these changes, we'd need to document how to fix projects which were already broken by this bug (or which inadvertently get broken before upgrading to this new fixed margarita).
Yes this is a very important piece.
Does that sound reasonable?
I think it's a fair short-term solution. I don't know what the solution is long term. We can't stay on an unpatched version of pip forever :( 16.04 ships with 8.1.X so it's unclear how Salt will work there.
This is fixed in the short-term by #131 (which I confirmed to be working on vagrant). Should we keep this open while we come up with a long term fix?
We might have to do something like "if salt version < (version they fix this in) then pin pip to 8.1.1". Which we can't really do until they fix it in salt, of course.
As of 2.0.0, we now only pin pip for old salt versions. Users of salt versions >= 2016.3.2 will get upgraded pip versions.
There is a conflict with Salt and Pip 8.1.2 https://github.com/saltstack/salt/issues/33163. The error was reported for 2015.8 but it impacts more versions than that. Currently the
ptyhon/init.sls
will always upgrade the global pip to the saltest which in hindsight was a poor decision. This was done because thepython-pip
package was falling far out of date (which is still the case). However, living on the cutting edge isn't a great choice either and we need to be able to hold this back.