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
