Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[James E. Blair]

Clark Boylan  writes:

...

> I've since worked out a change that passes tempest using a global
> virtualenv installed devstack at
> https://review.openstack.org/#/c/558930/. This needs to be cleaned up
> so that we only check for and install the virtualenv(s) once and we
> need to handle mixed python2 and python3 environments better (so that
> you can run a python2 swift and python3 everything else).
>
> The other major issue we've run into is that nova file injection
> (which is tested by tempest) seems to require either libguestfs or
> nbd. libguestfs bindings for python aren't available on pypi and
> instead we get them from system packaging. This means if we want
> libguestfs support we have to enable system site packages when using
> virtualenvs. The alternative is to use nbd which apparently isn't
> preferred by nova and doesn't work under current devstack anyways.
>
> Why is this a problem? Well the new pip10 behavior that breaks
> devstack is pip10's refusable to remove distutils installed
> packages. Distro packages by and large are distutils packaged which
> means if you mix system packages and pip installed packages there is a
> good chance something will break (and it does break for current
> devstack). I'm not sure that using a virtualenv with system site
> packages enabled will sufficiently protect us from this case (but we
> should test it further). Also it feels wrong to enable system packages
> in a virtualenv if the entire point is avoiding system python
> packages.
>
> I'm not sure what the best option is here but if we can show that
> system site packages with virtualenvs is viable with pip10 and people
> want to move forward with devstack using a global virtualenv we can
> work to clean up this change and make it mergeable.

Now that pip 10 is here and we've got things relatively stable, it's
probably time to revisit this.

I think we should continue to explore the route that Clark has opened
up.  This isn't an emergency because all of the current devstack/pip10
conflicts have been resolved, however, there's no guarantee that
we won't add a new package with a conflict (which may be even more
difficult to resolve) or even that a future pip won't take an even
harder line.

I believe that installing all in one virtualenv has the advantage of
behaving more like what is expected of a project in the current python
ecosystem, while still retaining the co-installability testing that we
get with devstack.

What I'm a bit fuzzy on is how this impacts devstack plugins or related
applications.  However, it seems to me that we ought to be able to
essentially define the global venv as part of the API and then plugins
can participate in it.  Perhaps that won't be able to be automatic?
Maybe we'll need to set this up and then all devstack plugins will need
to change in order to use it?  If so, hopefully we'll be able to export
the functions needed to make that easy.

-Jim

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Paul Belanger]

On Sat, Apr 07, 2018 at 12:56:31AM -0700, Arun SAG wrote:
> Hello,
> 
> On Thu, Apr 5, 2018 at 5:39 PM, Paul Belanger  wrote:
> 
> > Yah, I agree your approach is the better, i just wanted to toggle what was
> > supported by default. However, it is pretty broken today.  I can't imagine
> > anybody actually using it, if so they must be carrying downstream patches.
> >
> > If we think USE_VENV is valid use case, for per project VENV, I suggest we
> > continue to fix it and update neutron to support it.  Otherwise, we maybe 
> > should
> > rip and replace it.
> 
> I work for Yahoo (Oath). We use USE_VENV a lot in our CI. We use VENVs
> to deploy software to
> production as well. we have some downstream patches to devstack to fix
> some issues with
> USE_VENV feature, i would be happy to upstream them. Please do not rip
> this out. Thanks.
> 
Yes, please upstream them if at all possible. I've been tracking all the fixes
so far at https://review.openstack.org/552939/ but still having an issue with
rootwrap.  I think clarkb managed to fix this in his patchset.

Paul

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Andrea Frittoli]

On Thu, Apr 5, 2018 at 9:27 PM Clark Boylan  wrote:

> On Mon, Apr 2, 2018, at 9:13 AM, Clark Boylan wrote:
> > On Mon, Apr 2, 2018, at 8:06 AM, Matthew Thode wrote:
> > > On 18-03-31 15:00:27, Jeremy Stanley wrote:
> > > > According to a notice[1] posted to the pypa-announce and
> > > > distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0
> > > > is expected to be released in two weeks (over the April 14/15
> > > > weekend). We know it's at least going to start breaking[2] DevStack
> > > > and we need to come up with a plan for addressing that, but we don't
> > > > know how much more widespread the problem might end up being so
> > > > encourage everyone to try it out now where they can.
> > > >
> > >
> > > I'd like to suggest locking down pip/setuptools/wheel like openstack
> > > ansible is doing in
> > >
> https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt
> > >
> > > We could maintain it as a separate constraints file (or infra could
> > > maintian it, doesn't mater).  The file would only be used for the
> > > initial get-pip install.
> >
> > In the past we've done our best to avoid pinning these tools because 1)
> > we've told people they should use latest for openstack to work and 2) it
> > is really difficult to actually control what versions of these tools end
> > up on your systems if not latest.
> >
> > I would strongly push towards addressing the distutils package deletion
> > problem that we've run into with pip10 instead. One of the approaches
> > thrown out that pabelanger is working on is to use a common virtualenv
> > for devstack and avoid the system package conflict entirely.
>
> I was mistaken and pabelanger was working to get devstack's USE_VENV
> option working which installs each service (if the service supports it)
> into its own virtualenv. There are two big drawbacks to this. This first is
> that we would lose coinstallation of all the openstack services which is
> one way we ensure they all work together at the end of the day. The second
> is that not all services in "base" devstack support USE_VENV and I doubt
> many plugins do either (neutron apparently doesn't?).
>
> I've since worked out a change that passes tempest using a global
> virtualenv installed devstack at https://review.openstack.org/#/c/558930/.
> This needs to be cleaned up so that we only check for and install the
> virtualenv(s) once and we need to handle mixed python2 and python3
> environments better (so that you can run a python2 swift and python3
> everything else).
>
> The other major issue we've run into is that nova file injection (which is
> tested by tempest) seems to require either libguestfs or nbd. libguestfs
> bindings for python aren't available on pypi and instead we get them from
> system packaging. This means if we want libguestfs support we have to
> enable system site packages when using virtualenvs. The alternative is to
> use nbd which apparently isn't preferred by nova and doesn't work under
> current devstack anyways.
>
> Why is this a problem? Well the new pip10 behavior that breaks devstack is
> pip10's refusable to remove distutils installed packages. Distro packages
> by and large are distutils packaged which means if you mix system packages
> and pip installed packages there is a good chance something will break (and
> it does break for current devstack). I'm not sure that using a virtualenv
> with system site packages enabled will sufficiently protect us from this
> case (but we should test it further). Also it feels wrong to enable system
> packages in a virtualenv if the entire point is avoiding system python
> packages.
>
> I'm not sure what the best option is here but if we can show that system
> site packages with virtualenvs is viable with pip10 and people want to move
> forward with devstack using a global virtualenv we can work to clean up
> this change and make it mergeable.
>

Thanks Clark for looking into this.

One of the things that will break using a global virtual env is the
"all-plugin" Tempest tox environment, which is still used in a few places
[0].
The "all-plugin" tox environment is deprecated anyways, so this may
actually push things moving in the right direction.

Some background the "all-plugin": Tempest plugins used to live in tree for
many projects - for Tempest to discover those plugins, "all-plugin"
installs Tempest in a virtual environment with system site-packages
enabled. After the Tempest plugin community goal in Queens, most plugins
are now hosted in a dedicated repository, and "all-plugin" should not be
needed anymore.

Andrea Frittoli (andreaf)

[0] http://codesearch.openstack.org/?q=all-plugin=nope==


>
> Clark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Arun SAG]

Hello,

On Thu, Apr 5, 2018 at 5:39 PM, Paul Belanger  wrote:

> Yah, I agree your approach is the better, i just wanted to toggle what was
> supported by default. However, it is pretty broken today.  I can't imagine
> anybody actually using it, if so they must be carrying downstream patches.
>
> If we think USE_VENV is valid use case, for per project VENV, I suggest we
> continue to fix it and update neutron to support it.  Otherwise, we maybe 
> should
> rip and replace it.

I work for Yahoo (Oath). We use USE_VENV a lot in our CI. We use VENVs
to deploy software to
production as well. we have some downstream patches to devstack to fix
some issues with
USE_VENV feature, i would be happy to upstream them. Please do not rip
this out. Thanks.


-- 
Arun S A G
http://zer0c00l.in/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Monty Taylor]

On 04/05/2018 07:39 PM, Paul Belanger wrote:

On Thu, Apr 05, 2018 at 01:27:13PM -0700, Clark Boylan wrote:

On Mon, Apr 2, 2018, at 9:13 AM, Clark Boylan wrote:

On Mon, Apr 2, 2018, at 8:06 AM, Matthew Thode wrote:

On 18-03-31 15:00:27, Jeremy Stanley wrote:

According to a notice[1] posted to the pypa-announce and
distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0
is expected to be released in two weeks (over the April 14/15
weekend). We know it's at least going to start breaking[2] DevStack
and we need to come up with a plan for addressing that, but we don't
know how much more widespread the problem might end up being so
encourage everyone to try it out now where they can.



I'd like to suggest locking down pip/setuptools/wheel like openstack
ansible is doing in
https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt

We could maintain it as a separate constraints file (or infra could
maintian it, doesn't mater).  The file would only be used for the
initial get-pip install.


In the past we've done our best to avoid pinning these tools because 1)
we've told people they should use latest for openstack to work and 2) it
is really difficult to actually control what versions of these tools end
up on your systems if not latest.

I would strongly push towards addressing the distutils package deletion
problem that we've run into with pip10 instead. One of the approaches
thrown out that pabelanger is working on is to use a common virtualenv
for devstack and avoid the system package conflict entirely.


I was mistaken and pabelanger was working to get devstack's USE_VENV option working which 
installs each service (if the service supports it) into its own virtualenv. There are two 
big drawbacks to this. This first is that we would lose coinstallation of all the 
openstack services which is one way we ensure they all work together at the end of the 
day. The second is that not all services in "base" devstack support USE_VENV 
and I doubt many plugins do either (neutron apparently doesn't?).


Yah, I agree your approach is the better, i just wanted to toggle what was
supported by default. However, it is pretty broken today.  I can't imagine
anybody actually using it, if so they must be carrying downstream patches.

If we think USE_VENV is valid use case, for per project VENV, I suggest we
continue to fix it and update neutron to support it.  Otherwise, we maybe should
rip and replace it.


I'd vote for ripping it out.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Paul Belanger]

On Thu, Apr 05, 2018 at 01:27:13PM -0700, Clark Boylan wrote:
> On Mon, Apr 2, 2018, at 9:13 AM, Clark Boylan wrote:
> > On Mon, Apr 2, 2018, at 8:06 AM, Matthew Thode wrote:
> > > On 18-03-31 15:00:27, Jeremy Stanley wrote:
> > > > According to a notice[1] posted to the pypa-announce and
> > > > distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0
> > > > is expected to be released in two weeks (over the April 14/15
> > > > weekend). We know it's at least going to start breaking[2] DevStack
> > > > and we need to come up with a plan for addressing that, but we don't
> > > > know how much more widespread the problem might end up being so
> > > > encourage everyone to try it out now where they can.
> > > > 
> > > 
> > > I'd like to suggest locking down pip/setuptools/wheel like openstack
> > > ansible is doing in 
> > > https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt
> > > 
> > > We could maintain it as a separate constraints file (or infra could
> > > maintian it, doesn't mater).  The file would only be used for the
> > > initial get-pip install.
> > 
> > In the past we've done our best to avoid pinning these tools because 1) 
> > we've told people they should use latest for openstack to work and 2) it 
> > is really difficult to actually control what versions of these tools end 
> > up on your systems if not latest.
> > 
> > I would strongly push towards addressing the distutils package deletion 
> > problem that we've run into with pip10 instead. One of the approaches 
> > thrown out that pabelanger is working on is to use a common virtualenv 
> > for devstack and avoid the system package conflict entirely.
> 
> I was mistaken and pabelanger was working to get devstack's USE_VENV option 
> working which installs each service (if the service supports it) into its own 
> virtualenv. There are two big drawbacks to this. This first is that we would 
> lose coinstallation of all the openstack services which is one way we ensure 
> they all work together at the end of the day. The second is that not all 
> services in "base" devstack support USE_VENV and I doubt many plugins do 
> either (neutron apparently doesn't?).
> 
Yah, I agree your approach is the better, i just wanted to toggle what was
supported by default. However, it is pretty broken today.  I can't imagine
anybody actually using it, if so they must be carrying downstream patches.

If we think USE_VENV is valid use case, for per project VENV, I suggest we
continue to fix it and update neutron to support it.  Otherwise, we maybe should
rip and replace it.

Paul

> I've since worked out a change that passes tempest using a global virtualenv 
> installed devstack at https://review.openstack.org/#/c/558930/. This needs to 
> be cleaned up so that we only check for and install the virtualenv(s) once 
> and we need to handle mixed python2 and python3 environments better (so that 
> you can run a python2 swift and python3 everything else).
> 
> The other major issue we've run into is that nova file injection (which is 
> tested by tempest) seems to require either libguestfs or nbd. libguestfs 
> bindings for python aren't available on pypi and instead we get them from 
> system packaging. This means if we want libguestfs support we have to enable 
> system site packages when using virtualenvs. The alternative is to use nbd 
> which apparently isn't preferred by nova and doesn't work under current 
> devstack anyways.
> 
> Why is this a problem? Well the new pip10 behavior that breaks devstack is 
> pip10's refusable to remove distutils installed packages. Distro packages by 
> and large are distutils packaged which means if you mix system packages and 
> pip installed packages there is a good chance something will break (and it 
> does break for current devstack). I'm not sure that using a virtualenv with 
> system site packages enabled will sufficiently protect us from this case (but 
> we should test it further). Also it feels wrong to enable system packages in 
> a virtualenv if the entire point is avoiding system python packages.
> 
> I'm not sure what the best option is here but if we can show that system site 
> packages with virtualenvs is viable with pip10 and people want to move 
> forward with devstack using a global virtualenv we can work to clean up this 
> change and make it mergeable.
> 
> Clark
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Clark Boylan]

On Thu, Apr 5, 2018, at 1:27 PM, Clark Boylan wrote:
> The other major issue we've run into is that nova file injection (which 
> is tested by tempest) seems to require either libguestfs or nbd. 
> libguestfs bindings for python aren't available on pypi and instead we 
> get them from system packaging. This means if we want libguestfs support 
> we have to enable system site packages when using virtualenvs. The 
> alternative is to use nbd which apparently isn't preferred by nova and 
> doesn't work under current devstack anyways.
> 
> Why is this a problem? Well the new pip10 behavior that breaks devstack 
> is pip10's refusable to remove distutils installed packages. Distro 
> packages by and large are distutils packaged which means if you mix 
> system packages and pip installed packages there is a good chance 
> something will break (and it does break for current devstack). I'm not 
> sure that using a virtualenv with system site packages enabled will 
> sufficiently protect us from this case (but we should test it further). 
> Also it feels wrong to enable system packages in a virtualenv if the 
> entire point is avoiding system python packages.

Good news everyone, 
http://logs.openstack.org/74/559174/1/check/tempest-full-py3/4c5548f/job-output.txt.gz#_2018-04-05_21_26_36_669943
 shows the pip10 appears to do the right thing with a virtualenv using 
system-site-package option when attempting to install a newer version of a 
package that would require being deleted if done on the system python proper.

It determines there is an existing package, that it is outside the env and it 
cannot uninstall it, then installs a newer version of the package anyways.

If you look later in the job run you'll see it fails in the system python 
context on this same package, 
http://logs.openstack.org/74/559174/1/check/tempest-full-py3/4c5548f/job-output.txt.gz#_2018-04-05_21_29_31_399895.

I think that means this is a viable workaround for us even if it isn't ideal.

Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Luigi Toscano]

On Thursday, 5 April 2018 22:44:32 CEST Jeremy Stanley wrote:
> On 2018-04-05 13:27:13 -0700 (-0700), Clark Boylan wrote:
> [...]
> 
> > I'm not sure what the best option is here but if we can show that
> > system site packages with virtualenvs is viable with pip10 and
> > people want to move forward with devstack using a global
> > virtualenv we can work to clean up this change and make it
> > mergeable.
> 
> Ideally, someone convinces the libguestfs authors of the benefits of
> putting sdist/wheel builds of their python module on PyPI like
> (eventually) happened with libvirt.

It may be not trivial:
https://bugzilla.redhat.com/show_bug.cgi?id=1075594

On the other side, not being able to use system site packages with a 
virtualenv does not sound good either.

Ciao
-- 
Luigi



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Jeremy Stanley]

On 2018-04-05 13:27:13 -0700 (-0700), Clark Boylan wrote:
[...]
> I'm not sure what the best option is here but if we can show that
> system site packages with virtualenvs is viable with pip10 and
> people want to move forward with devstack using a global
> virtualenv we can work to clean up this change and make it
> mergeable.

Ideally, someone convinces the libguestfs authors of the benefits of
putting sdist/wheel builds of their python module on PyPI like
(eventually) happened with libvirt.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Clark Boylan]

On Mon, Apr 2, 2018, at 9:13 AM, Clark Boylan wrote:
> On Mon, Apr 2, 2018, at 8:06 AM, Matthew Thode wrote:
> > On 18-03-31 15:00:27, Jeremy Stanley wrote:
> > > According to a notice[1] posted to the pypa-announce and
> > > distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0
> > > is expected to be released in two weeks (over the April 14/15
> > > weekend). We know it's at least going to start breaking[2] DevStack
> > > and we need to come up with a plan for addressing that, but we don't
> > > know how much more widespread the problem might end up being so
> > > encourage everyone to try it out now where they can.
> > > 
> > 
> > I'd like to suggest locking down pip/setuptools/wheel like openstack
> > ansible is doing in 
> > https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt
> > 
> > We could maintain it as a separate constraints file (or infra could
> > maintian it, doesn't mater).  The file would only be used for the
> > initial get-pip install.
> 
> In the past we've done our best to avoid pinning these tools because 1) 
> we've told people they should use latest for openstack to work and 2) it 
> is really difficult to actually control what versions of these tools end 
> up on your systems if not latest.
> 
> I would strongly push towards addressing the distutils package deletion 
> problem that we've run into with pip10 instead. One of the approaches 
> thrown out that pabelanger is working on is to use a common virtualenv 
> for devstack and avoid the system package conflict entirely.

I was mistaken and pabelanger was working to get devstack's USE_VENV option 
working which installs each service (if the service supports it) into its own 
virtualenv. There are two big drawbacks to this. This first is that we would 
lose coinstallation of all the openstack services which is one way we ensure 
they all work together at the end of the day. The second is that not all 
services in "base" devstack support USE_VENV and I doubt many plugins do either 
(neutron apparently doesn't?).

I've since worked out a change that passes tempest using a global virtualenv 
installed devstack at https://review.openstack.org/#/c/558930/. This needs to 
be cleaned up so that we only check for and install the virtualenv(s) once and 
we need to handle mixed python2 and python3 environments better (so that you 
can run a python2 swift and python3 everything else).

The other major issue we've run into is that nova file injection (which is 
tested by tempest) seems to require either libguestfs or nbd. libguestfs 
bindings for python aren't available on pypi and instead we get them from 
system packaging. This means if we want libguestfs support we have to enable 
system site packages when using virtualenvs. The alternative is to use nbd 
which apparently isn't preferred by nova and doesn't work under current 
devstack anyways.

Why is this a problem? Well the new pip10 behavior that breaks devstack is 
pip10's refusable to remove distutils installed packages. Distro packages by 
and large are distutils packaged which means if you mix system packages and pip 
installed packages there is a good chance something will break (and it does 
break for current devstack). I'm not sure that using a virtualenv with system 
site packages enabled will sufficiently protect us from this case (but we 
should test it further). Also it feels wrong to enable system packages in a 
virtualenv if the entire point is avoiding system python packages.

I'm not sure what the best option is here but if we can show that system site 
packages with virtualenvs is viable with pip10 and people want to move forward 
with devstack using a global virtualenv we can work to clean up this change and 
make it mergeable.

Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Clark Boylan]

On Mon, Apr 2, 2018, at 8:06 AM, Matthew Thode wrote:
> On 18-03-31 15:00:27, Jeremy Stanley wrote:
> > According to a notice[1] posted to the pypa-announce and
> > distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0
> > is expected to be released in two weeks (over the April 14/15
> > weekend). We know it's at least going to start breaking[2] DevStack
> > and we need to come up with a plan for addressing that, but we don't
> > know how much more widespread the problem might end up being so
> > encourage everyone to try it out now where they can.
> > 
> 
> I'd like to suggest locking down pip/setuptools/wheel like openstack
> ansible is doing in 
> https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt
> 
> We could maintain it as a separate constraints file (or infra could
> maintian it, doesn't mater).  The file would only be used for the
> initial get-pip install.

In the past we've done our best to avoid pinning these tools because 1) we've 
told people they should use latest for openstack to work and 2) it is really 
difficult to actually control what versions of these tools end up on your 
systems if not latest.

I would strongly push towards addressing the distutils package deletion problem 
that we've run into with pip10 instead. One of the approaches thrown out that 
pabelanger is working on is to use a common virtualenv for devstack and avoid 
the system package conflict entirely.

Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][qa][requirements] Pip 10 is on the way

[Matthew Thode]

On 18-03-31 15:00:27, Jeremy Stanley wrote:
> According to a notice[1] posted to the pypa-announce and
> distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0
> is expected to be released in two weeks (over the April 14/15
> weekend). We know it's at least going to start breaking[2] DevStack
> and we need to come up with a plan for addressing that, but we don't
> know how much more widespread the problem might end up being so
> encourage everyone to try it out now where they can.
> 

I'd like to suggest locking down pip/setuptools/wheel like openstack
ansible is doing in 
https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt

We could maintain it as a separate constraints file (or infra could
maintian it, doesn't mater).  The file would only be used for the
initial get-pip install.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev