settingsLogin | Registersettings

[openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions

0 votes

Hello,

As many of you know, during Kilo, the neutron vendor decomposition happened, which lead to the birth of many networking-* libraries, including networking-hyperv. When it was time for us to make a release for that cycle, pretty much every networking-* project followed the release version number at that time, which was 2015.1.0. After Kilo, the versioning changed to the current format.

networking-hyperv currently contains the "hyperv" mechanism_driver, which is needed in order to bind neutron ports to Hyper-V compute nodes using neutron-hyperv-agent L2 agents.

Now, my main issue is that networking-hyperv==2015.1.0 is currently on Pypi, and whenever someone upgrades networking-hyperv through pip (pip install -U networking-hyperv), it "upgrades" to 2015.1.0. And even if it isn't already installed, networking-hyperv==2015.1.0 is installed, as that is considered the "latest" version:

(test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv

(test) ubuntu@ubuntu:~$ pip install networking-hyperv
...
(test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv
networking-hyperv==2015.1.0

This is a common pitfall for people using pip to install / upgrade networking-hyperv. It's actually become a ritual for new developers to mistakenly install the "latest" version. :)

Now, my question is: could we / should we unpublish the 2015.1.0 version?

[1] Kolla using pip package "networking-hyperv>=5.0.0,<6.0.0" https://review.openstack.org/#/c/498409/1
[1] #openstack-release: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T08:19:28
[2] #openstack-release: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T13:20:36

Best regards,

Claudiu Belu


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Sep 1, 2017 in openstack-dev by Claudiu_Belu (1,200 points)   2

19 Responses

0 votes

On 17-08-29 14:09:32, Claudiu Belu wrote:
Hello,

As many of you know, during Kilo, the neutron vendor decomposition happened, which lead to the birth of many networking-* libraries, including networking-hyperv. When it was time for us to make a release for that cycle, pretty much every networking-* project followed the release version number at that time, which was 2015.1.0. After Kilo, the versioning changed to the current format.

networking-hyperv currently contains the "hyperv" mechanism_driver, which is needed in order to bind neutron ports to Hyper-V compute nodes using neutron-hyperv-agent L2 agents.

Now, my main issue is that networking-hyperv==2015.1.0 is currently on Pypi, and whenever someone upgrades networking-hyperv through pip (pip install -U networking-hyperv), it "upgrades" to 2015.1.0. And even if it isn't already installed, networking-hyperv==2015.1.0 is installed, as that is considered the "latest" version:

(test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv

(test) ubuntu@ubuntu:~$ pip install networking-hyperv
...
(test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv
networking-hyperv==2015.1.0

This is a common pitfall for people using pip to install / upgrade networking-hyperv. It's actually become a ritual for new developers to mistakenly install the "latest" version. :)

Now, my question is: could we / should we unpublish the 2015.1.0 version?

[1] Kolla using pip package "networking-hyperv>=5.0.0,<6.0.0" https://review.openstack.org/#/c/498409/1
[1] #openstack-release: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T08:19:28
[2] #openstack-release: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T13:20:36

Best regards,

Claudiu Belu


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

I think we have three options here.

  1. Unpublish. This is probably the simplest, but generally goes against
    the policy of pypi to never unpublish things (it is not a hard and fast
    rule though).

  2. Rename. A bunch of work for downstreams but technically
    cleaner/better than unpublishing, allows a more consistant naming scheme
    to be used if desired at least.

  3. reversion. Start new versions at 3000 or something, kinda dirty imo.

--
Matthew Thode (prometheanfire)


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

responded Aug 29, 2017 by prometheanfire_at_ge (6,880 points)   1 4 5
0 votes

Excerpts from Claudiu Belu's message of 2017-08-29 14:09:32 +0000:

Hello,

As many of you know, during Kilo, the neutron vendor decomposition happened, which lead to the birth of many networking-* libraries, including networking-hyperv. When it was time for us to make a release for that cycle, pretty much every networking-* project followed the release version number at that time, which was 2015.1.0. After Kilo, the versioning changed to the current format.

networking-hyperv currently contains the "hyperv" mechanism_driver, which is needed in order to bind neutron ports to Hyper-V compute nodes using neutron-hyperv-agent L2 agents.

Now, my main issue is that networking-hyperv==2015.1.0 is currently on Pypi, and whenever someone upgrades networking-hyperv through pip (pip install -U networking-hyperv), it "upgrades" to 2015.1.0. And even if it isn't already installed, networking-hyperv==2015.1.0 is installed, as that is considered the "latest" version:

(test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv

(test) ubuntu@ubuntu:~$ pip install networking-hyperv
...
(test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv
networking-hyperv==2015.1.0

This is a common pitfall for people using pip to install / upgrade networking-hyperv. It's actually become a ritual for new developers to mistakenly install the "latest" version. :)

Now, my question is: could we / should we unpublish the 2015.1.0 version?

[1] Kolla using pip package "networking-hyperv>=5.0.0,<6.0.0" https://review.openstack.org/#/c/498409/1
[1] #openstack-release: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T08:19:28
[2] #openstack-release: http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T13:20:36

Best regards,

Claudiu Belu

Thierry mentioned in #openstack-release that this issue did come
up when we originally changed to using SemVer. However, at that
time we only had service projects using date-based versions and we
did not support installing those from PyPI. Distribution packages
updated their epoch setting, which allowed them to reset the rest
of the version number to an apparently lower value and still have
it considered as newer. Python packaging doesn't have that sort
of ability, unfortunately.

If that 2015 version is no longer maintained, then deleting it from
PyPI may be the most effective way to avoid this particular support
issue, even though that is normally not something we recommend.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 29, 2017 by Doug_Hellmann (87,520 points)   3 4 12
0 votes

On 2017-08-29 10:30:42 -0500 (-0500), Matthew Thode wrote:
[...]
3. reversion. Start new versions at 3000 or something, kinda
dirty imo.

And sort of a 3.1 option is to prepend a PEP 440 version epoch:

https://www.python.org/dev/peps/pep-0440/#version-epochs

Challenge there is that, while Git can handle a ! in a tag name, PBR
doesn't know to sort that after implicit 0 epochs nor does a lot of
our release automation have the ability to cope with version epochs
and adding support for them would entail a lot of careful work and
thorough testing. Also having upstream epochs could wreak havoc with
downstream distro package maintainers, look confusing in
tarball/wheel filenames (hopefully all modern platforms are at least
not going to break when there's a ! in a filename), and so on.

The concerns were touched on in this thread from 2015 when the
versioning changes were going into effect:

http://lists.openstack.org/pipermail/openstack-dev/2015-July/069085.html

Pretty unlikely to happen if you ask me. I'm just bringing it up
preemptively since odds are someone else with less history/memory of
the scenarios we discussed back then is likely to bring it up as a
silver bullet solution otherwise.
--
Jeremy Stanley


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

responded Aug 29, 2017 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

Doug Hellmann wrote:
If that 2015 version is no longer maintained, then deleting it from
PyPI may be the most effective way to avoid this particular support
issue, even though that is normally not something we recommend.

Yeah, in that specific case I think that's the simplest route. It's not
really destroying it, it just prevents PyPI from erroneously
distributing it, without having to add a PEP440-Epoch to an OpenStack
deliverable and discovering all the bugs that it would trigger.

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 29, 2017 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

On 2017-08-29 18:26:49 +0200 (+0200), Thierry Carrez wrote:
[...]
Yeah, in that specific case I think that's the simplest route. It's not
really destroying it, it just prevents PyPI from erroneously
distributing it, without having to add a PEP440-Epoch to an OpenStack
deliverable and discovering all the bugs that it would trigger.

Agreed, we even still make it available from tarballs.openstack.org
in case someone doesn't want to have to try and rebuild it from the
tag.
--
Jeremy Stanley


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

responded Aug 29, 2017 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

On Tue, Aug 29, 2017 at 02:09:32PM +0000, Claudiu Belu wrote:

(test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv

(test) ubuntu@ubuntu:~$ pip install networking-hyperv

I know this isn't a solution but I'd be remiss if I didn't point it out:

ucurl=https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt
pip install -c "$uc
url" networking-hyperv

will do the right thing

This is a common pitfall for people using pip to install / upgrade
networking-hyperv. It's actually become a ritual for new developers to
mistakenly install the "latest" version. :)

Now, my question is: could we / should we unpublish the 2015.1.0 version?

Seems like that's the best thing to do.

An extension to this would be to check for other items in the same boat.
I wrote [1] to find anything in the openstack namespace that isn't a
service and has something that looks like a date based release on pypi.

Clearly this is a very rough check but it looks like potentially have a
few things we could clean up, the hard part is working with the affected
projects teams to decide the correct action.


python-congressclient has 2015.1.0 which might need to be unpublished
python-congressclient has 2015.1.0rc1 which might need to be unpublished
group-based-policy has 2015.1.1 which might need to be unpublished
group-based-policy has 2014.2.1 which might need to be unpublished
group-based-policy has 2015.1.3 which might need to be unpublished
group-based-policy has 2015.1.0b1 which might need to be unpublished
group-based-policy has 2014.2.10 which might need to be unpublished
group-based-policy has 2015.2.7 which might need to be unpublished
group-based-policy has 2015.2.4 which might need to be unpublished
group-based-policy has 2015.2.5 which might need to be unpublished
group-based-policy has 2015.2.2 which might need to be unpublished
group-based-policy has 2015.2.3 which might need to be unpublished
group-based-policy has 2015.2.0 which might need to be unpublished
group-based-policy has 2015.2.1 which might need to be unpublished
group-based-policy has 2015.1.0b2 which might need to be unpublished
group-based-policy has 2015.2.8 which might need to be unpublished
group-based-policy has 2015.1.7 which might need to be unpublished
group-based-policy has 2014.2rc1 which might need to be unpublished
group-based-policy has 2015.1.0 which might need to be unpublished
group-based-policy has 2014.2rc3 which might need to be unpublished
group-based-policy has 2014.2rc2 which might need to be unpublished
group-based-policy has 2015.1.5 which might need to be unpublished
group-based-policy has 2015.1.4 which might need to be unpublished
group-based-policy has 2015.1.6 which might need to be unpublished
group-based-policy has 2015.1.9 which might need to be unpublished
group-based-policy has 2015.1.8 which might need to be unpublished
group-based-policy has 2014.2.0rc1 which might need to be unpublished
group-based-policy has 2014.2.4 which might need to be unpublished
group-based-policy has 2014.2.7 which might need to be unpublished
group-based-policy has 2014.2.6 which might need to be unpublished
group-based-policy has 2014.2.5 which might need to be unpublished
group-based-policy has 2014.2.3 which might need to be unpublished
group-based-policy has 2014.2.2 which might need to be unpublished
group-based-policy has 2014.2.8 which might need to be unpublished
group-based-policy has 2015.1.2 which might need to be unpublished
group-based-policy has 2014.2.9 which might need to be unpublished
group-based-policy has 2014.2 which might need to be unpublished
mistral-extra has 2015.1.0 which might need to be unpublished
networking-fujitsu has 2015.1.1 which might need to be unpublished
networking-fujitsu has 2015.1.0 which might need to be unpublished
networking-fujitsu has 2015.2.0.dev7 which might need to be unpublished
networking-fujitsu has 2015.2.0 which might need to be unpublished
cloudpulse has 2016.1.1 which might need to be unpublished
cloudpulse has 2015.3.1 which might need to be unpublished
cloudpulse has 2015.2.6 which might need to be unpublished
cloudpulse has 2015.3.2 which might need to be unpublished
cloudpulse has 2015.2.4 which might need to be unpublished
cloudpulse has 2015.2.5 which might need to be unpublished
cloudpulse has 2015.2.3 which might need to be unpublished
cloudpulse has 2015.3.3 which might need to be unpublished
networking-odl has 2015.1.1 which might need to be unpublished
networking-odl has 2015.1.dev986 which might need to be unpublished
murano-dashboard has 2015.1.0b1 which might need to be unpublished
murano-dashboard has 2015.1.0b3 which might need to be unpublished
murano-dashboard has 2015.1.0b2 which might need to be unpublished
murano-dashboard has 2015.1.1 which might need to be unpublished
murano-dashboard has 2015.1.0 which might need to be unpublished
murano-dashboard has 2015.1.0rc1 which might need to be unpublished
murano-dashboard has 2014.2.4 which might need to be unpublished
murano-dashboard has 2014.2.2 which might need to be unpublished
murano-dashboard has 2014.2.1 which might need to be unpublished
murano-dashboard has 2014.2 which might need to be unpublished
networking-hpe has 2015.2.1.dev303 which might need to be unpublished
sahara-image-elements has 2014.1.1 which might need to be unpublished
sahara-image-elements has 2014.1.2 which might need to be unpublished
sahara-image-elements has 2014.1.3 which might need to be unpublished
sahara-image-elements has 2014.1 which might need to be unpublished
sahara-image-elements has 2014.2 which might need to be unpublished
group-based-policy-ui has 2015.1.1 which might need to be unpublished
group-based-policy-ui has 2014.2.1 which might need to be unpublished
group-based-policy-ui has 2015.1.0b1 which might need to be unpublished
group-based-policy-ui has 2015.1.0b2 which might need to be unpublished
group-based-policy-ui has 2015.1.7 which might need to be unpublished
group-based-policy-ui has 2015.2.4 which might need to be unpublished
group-based-policy-ui has 2015.2.5 which might need to be unpublished
group-based-policy-ui has 2015.2.2 which might need to be unpublished
group-based-policy-ui has 2015.2.3 which might need to be unpublished
group-based-policy-ui has 2015.2.0 which might need to be unpublished
group-based-policy-ui has 2015.2.1 which might need to be unpublished
group-based-policy-ui has 2014.2rc1 which might need to be unpublished
group-based-policy-ui has 2015.1.0 which might need to be unpublished
group-based-policy-ui has 2015.1.3 which might need to be unpublished
group-based-policy-ui has 2015.1.2 which might need to be unpublished
group-based-policy-ui has 2015.1.5 which might need to be unpublished
group-based-policy-ui has 2015.1.4 which might need to be unpublished
group-based-policy-ui has 2015.1.6 which might need to be unpublished
group-based-policy-ui has 2015.1.8 which might need to be unpublished
group-based-policy-ui has 2014.2.4 which might need to be unpublished
group-based-policy-ui has 2014.2.7 which might need to be unpublished
group-based-policy-ui has 2014.2.6 which might need to be unpublished
group-based-policy-ui has 2014.2.5 which might need to be unpublished
group-based-policy-ui has 2014.2.3 which might need to be unpublished
group-based-policy-ui has 2014.2.2 which might need to be unpublished
group-based-policy-ui has 2014.2.8 which might need to be unpublished
group-based-policy-ui has 2014.2 which might need to be unpublished
vmware-nsx has 2015.1.2 which might need to be unpublished
vmware-nsx has 2015.1.2.dev259 which might need to be unpublished
python-designateclient has 2013.1.a8.g3a2a320 which might need to be
unpublished
networking-plumgrid has 2015.2.1.1 which might need to be unpublished
networking-plumgrid has 2016.1.6.8 which might need to be unpublished
networking-plumgrid has 2016.1.6.4 which might need to be unpublished
networking-plumgrid has 2016.1.6.5 which might need to be unpublished
networking-plumgrid has 2016.1.6.6 which might need to be unpublished
networking-plumgrid has 2016.1.6.7 which might need to be unpublished
networking-plumgrid has 2016.1.6.0 which might need to be unpublished
networking-plumgrid has 2016.1.6.1 which might need to be unpublished
networking-plumgrid has 2016.1.6.2 which might need to be unpublished
networking-plumgrid has 2016.1.6.3 which might need to be unpublished
networking-plumgrid has 2015.2.4.1.3.1 which might need to be
unpublished
networking-plumgrid has 2015.1.5rc1 which might need to be unpublished
networking-plumgrid has 2015.1.5rc2 which might need to be unpublished
networking-plumgrid has 2015.2.6.8 which might need to be unpublished
networking-plumgrid has 2015.2.6.0 which might need to be unpublished
networking-plumgrid has 2015.2.6.1 which might need to be unpublished
networking-plumgrid has 2015.2.6.2 which might need to be unpublished
networking-plumgrid has 2015.2.6.3 which might need to be unpublished
networking-plumgrid has 2015.2.6.4 which might need to be unpublished
networking-plumgrid has 2015.2.6.5 which might need to be unpublished
networking-plumgrid has 2015.2.6.6 which might need to be unpublished
networking-plumgrid has 2015.2.6.7 which might need to be unpublished
networking-plumgrid has 2015.2.5rc1 which might need to be unpublished
networking-plumgrid has 2015.2.5rc2 which might need to be unpublished
networking-plumgrid has 2016.2.6.8 which might need to be unpublished
networking-plumgrid has 2015.1.1.1 which might need to be unpublished
networking-plumgrid has 2015.2.5.2 which might need to be unpublished
networking-plumgrid has 2015.1.5.4 which might need to be unpublished
networking-plumgrid has 2015.1.5.5 which might need to be unpublished
networking-plumgrid has 2015.2.5.5 which might need to be unpublished
networking-plumgrid has 2015.2.5.4 which might need to be unpublished
networking-plumgrid has 2015.2.5.3 which might need to be unpublished
networking-plumgrid has 2015.1.5.1 which might need to be unpublished
networking-plumgrid has 2015.2.5.1 which might need to be unpublished
networking-plumgrid has 2015.2.5.6 which might need to be unpublished
networking-plumgrid has 2015.1.5.3 which might need to be unpublished
networking-plumgrid has 2016.1.1.4 which might need to be unpublished
networking-plumgrid has 2016.1.1.3 which might need to be unpublished
networking-plumgrid has 2016.1.1.2 which might need to be unpublished
networking-plumgrid has 2016.1.1.1 which might need to be unpublished
networking-ofagent has 2015.1.3 which might need to be unpublished
networking-ofagent has 2015.1.2 which might need to be unpublished
networking-ofagent has 2015.1.5 which might need to be unpublished
networking-ofagent has 2015.1.4 which might need to be unpublished
networking-ofagent has 2015.1.6 which might need to be unpublished
networking-ofagent has 2015.1.1.dev97 which might need to be unpublished
networking-l2gw has 2015.1.1 which might need to be unpublished
networking-l2gw has 2016.1.0 which might need to be unpublished
freezer-api has 2015.1.0.dev28 which might need to be unpublished
networking-brocade has 2015.1.1.dev30 which might need to be unpublished
networking-brocade has 2015.1.1.dev34 which might need to be unpublished
networking-brocade has 2015.1.1.dev10 which might need to be unpublished
networking-brocade has 2015.1.1.dev39 which might need to be unpublished
networking-brocade has 2015.1.1.dev9 which might need to be unpublished
networking-brocade has 2015.1.1.dev23 which might need to be unpublished
networking-brocade has 2015.1.1.dev54 which might need to be unpublished
networking-brocade has 2015.1.1.dev55 which might need to be unpublished
murano-agent has 2015.1.0b1 which might need to be unpublished
murano-agent has 2015.1.0b3 which might need to be unpublished
murano-agent has 2015.1.0b2 which might need to be unpublished
murano-agent has 2015.1.0 which might need to be unpublished
murano-agent has 2015.1.0rc2 which might need to be unpublished
murano-agent has 2015.1.0rc1 which might need to be unpublished
murano-agent has 2014.2.4 which might need to be unpublished
murano-agent has 2014.2.2 which might need to be unpublished
murano-agent has 2014.2.1 which might need to be unpublished
murano-agent has 2014.2 which might need to be unpublished
networking-midonet has 2015.1.1 which might need to be unpublished
networking-midonet has 2015.1.0 which might need to be unpublished
networking-midonet has 2015.1.dev1 which might need to be unpublished
networking-midonet has 2015.1.4 which might need to be unpublished
networking-midonet has 2015.1.5.dev5 which might need to be unpublished
networking-midonet has 2015.1.0b4 which might need to be unpublished
networking-midonet has 2015.1.dev288 which might need to be unpublished
networking-midonet has 2014.2.2 which might need to be unpublished
networking-lenovo has 2015.1.0 which might need to be unpublished
networking-ale-omniswitch has 2015.1.2 which might need to be
unpublished
networking-arista has 2015.1.1.dev1 which might need to be unpublished
networking-arista has 2016.2.5 which might need to be unpublished
networking-arista has 2016.2.4 which might need to be unpublished
networking-arista has 2016.2.1 which might need to be unpublished
networking-arista has 2016.2.0 which might need to be unpublished
networking-arista has 2016.2.3 which might need to be unpublished
networking-arista has 2016.2.2 which might need to be unpublished
networking-arista has 2016.1.3 which might need to be unpublished
networking-arista has 2016.1.0 which might need to be unpublished
networking-arista has 2016.1.1 which might need to be unpublished
networking-arista has 2016.1.4 which might need to be unpublished
networking-arista has 2016.1.5 which might need to be unpublished
networking-arista has 2017.1.3 which might need to be unpublished
networking-arista has 2017.1.2 which might need to be unpublished
networking-arista has 2017.1.1 which might need to be unpublished
networking-arista has 2017.1.0 which might need to be unpublished
networking-arista has 2015.1.1.dev12 which might need to be unpublished
networking-arista has 2015.2.2 which might need to be unpublished
networking-arista has 2015.2.0 which might need to be unpublished
networking-arista has 2015.2.1 which might need to be unpublished
networking-arista has 2015.1.1 which might need to be unpublished
networking-arista has 2015.1.2 which might need to be unpublished
networking-arista has 2015.1.5 which might need to be unpublished
networking-arista has 2015.1.6 which might need to be unpublished
group-based-policy-automation has 2015.1.1 which might need to be
unpublished
group-based-policy-automation has 2015.1.0b1 which might need to be
unpublished
group-based-policy-automation has 2015.1.0b2 which might need to be
unpublished
group-based-policy-automation has 2014.2.4 which might need to be
unpublished
group-based-policy-automation has 2015.2.2 which might need to be
unpublished
group-based-policy-automation has 2014.2.1 which might need to be
unpublished
group-based-policy-automation has 2015.2.0 which might need to be
unpublished
group-based-policy-automation has 2015.2.1 which might need to be
unpublished
group-based-policy-automation has 2014.2rc1 which might need to be
unpublished
group-based-policy-automation has 2015.1.0 which might need to be
unpublished
group-based-policy-automation has 2015.1.3 which might need to be
unpublished
group-based-policy-automation has 2015.1.2 which might need to be
unpublished
group-based-policy-automation has 2015.1.4 which might need to be
unpublished
group-based-policy-automation has 2014.2.5 which might need to be
unpublished
group-based-policy-automation has 2014.2.3 which might need to be
unpublished
group-based-policy-automation has 2014.2.2 which might need to be
unpublished
group-based-policy-automation has 2014.2 which might need to be
unpublished
networking-vsphere has 2015.1.1 which might need to be unpublished
magnetodb has 2015.1.0b1 which might need to be unpublished
magnetodb has 2015.1.0b3 which might need to be unpublished
magnetodb has 2015.1.0b2 which might need to be unpublished
magnetodb has 2015.1 which might need to be unpublished
magnetodb has 2014.2.b3 which might need to be unpublished
magnetodb has 2014.2 which might need to be unpublished
python-cloudpulseclient has 2015.3.3 which might need to be unpublished
python-cloudpulseclient has 2015.3.2 which might need to be unpublished
python-cloudpulseclient has 2015.3.1 which might need to be unpublished
python-cloudpulseclient has 2015.2.3 which might need to be unpublished
mistral-dashboard has 2015.1.0b1 which might need to be unpublished
mistral-dashboard has 2015.1.0b3 which might need to be unpublished
mistral-dashboard has 2015.1.0b2 which might need to be unpublished
mistral-dashboard has 2015.1.0 which might need to be unpublished
mistral-dashboard has 2015.1.0rc1 which might need to be unpublished
sahara-dashboard has 2014.1 which might need to be unpublished
sahara-dashboard has 2014.1.1 which might need to be unpublished
sahara-dashboard has 2014.1.2 which might need to be unpublished
sahara-dashboard has 2014.1.3 which might need to be unpublished
sahara-dashboard has 2014.2.b2 which might need to be unpublished
sahara-dashboard has 2014.2.b1 which might need to be unpublished
networking-hyperv has 2015.1.0 which might need to be unpublished
networking-nec has 2015.1.1 which might need to be unpublished
networking-nec has 2015.1.0 which might need to be unpublished
networking-nec has 2015.1.2 which might need to be unpublished
networking-nec has 2015.2.0 which might need to be unpublished
networking-mlnx has 2015.1.2 which might need to be unpublished

Yours Tony.

[1] http://paste.openstack.org/show/619845/


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

responded Aug 30, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

Tony Breeds wrote:
An extension to this would be to check for other items in the same boat.
I wrote [1] to find anything in the openstack namespace that isn't a
service and has something that looks like a date based release on pypi.
[...]

Thanks for computing the list. Unpublishing is a bit of a trade-off --
in the networking-hyperv case the pain resulting from the people using
pip to install it (and complaining about the situation) ends up being
bigger than the pain of unpublishing it... So I'm not sure we should
necessarily proactively unpublish everything in the same boat
(especially if nobody asks for it). In particular, we should definitely
not do it for anything that's not an official OpenStack deliverable.

That leaves us with:

Official libraries (python-congressclient, python-designateclient) for
which I think we should proactively fix them ASAP.

Other official things (mistral-extra, networking-odl, murano-dashboard,
networking-hyperv, networking-midonet, sahara-image-elements,
freezer-api, murano-agent, mistral-dashboard, sahara-dashboard) for
which we should fix them if pip is a reasonable way of installing them
(after asking the local PTL if that's alright).

--
Thierry Carrez (ttx)


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

responded Aug 30, 2017 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

On Wed, Aug 30, 2017 at 05:04:58PM +0200, Thierry Carrez wrote:
Tony Breeds wrote:

An extension to this would be to check for other items in the same boat.
I wrote [1] to find anything in the openstack namespace that isn't a
service and has something that looks like a date based release on pypi.
[...]

Thanks for computing the list. Unpublishing is a bit of a trade-off --
in the networking-hyperv case the pain resulting from the people using
pip to install it (and complaining about the situation) ends up being
bigger than the pain of unpublishing it... So I'm not sure we should
necessarily proactively unpublish everything in the same boat
(especially if nobody asks for it). In particular, we should definitely
not do it for anything that's not an official OpenStack deliverable.

Okay I could tweak the tool to only check for repos that are in
openstack/governance:reference/projects.yaml but it looks like you've
already done that translation in your head ;P

That leaves us with:

Official libraries (python-congressclient, python-designateclient) for
which I think we should proactively fix them ASAP.

Other official things (mistral-extra, networking-odl, murano-dashboard,
networking-hyperv, networking-midonet, sahara-image-elements,
freezer-api, murano-agent, mistral-dashboard, sahara-dashboard) for
which we should fix them if pip is a reasonable way of installing them
(after asking the local PTL if that's alright).

Cool. If we don't get any traction here can use the PTG to find PTLs ;P

I assume it's infra that needs to do the actual unpublish?

Yours Tony.


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

responded Aug 31, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

On 2017-08-31 15:21:19 +1000 (+1000), Tony Breeds wrote:
[...]
I assume it's infra that needs to do the actual unpublish?

We're the ones with the most consistent access to all of them,
though in a majority of cases there's at least one other account
with sufficient access to do the same (it just tends to vary by team
and origination timeframe). So, yes, probably easiest to give the
Infra team a list once it's been confirmed.
--
Jeremy Stanley


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

responded Aug 31, 2017 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

So, I believe the general consensus is that the easiest thing to do is to unpublish the 2015.1.0 version from pypi, with which I also agree.

Even if someone actually needs the Kilo version (it's a very old branch, very few people still use it, at most), it can still be done via [1]:

pip install git+http://github.com/openstack/networking-hyperv@2015.1.0#networking-hyperv

or

pip install http://tarballs.openstack.org/networking-hyperv/networking_hyperv-2015.1.0-py2-none-any.whl

If someone actually needs it on pypi, We could publish a 0.x.y version, but I don't think it will be necessary.

Also, @Tony, using upper-constraints wouldn't work when installing networking-hyperv won't really help, as it isn't defined there. networking-hyperv is not a requirement in any project, it's only needed by neutron if the "hyperv" mechanism_driver is used.

Thanks @all for your opinions!

Best regards,

Claudiu Belu


From: Jeremy Stanley [fungi@yuggoth.org]
Sent: Thursday, August 31, 2017 3:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions

On 2017-08-31 15:21:19 +1000 (+1000), Tony Breeds wrote:
[...]
I assume it's infra that needs to do the actual unpublish?

We're the ones with the most consistent access to all of them,
though in a majority of cases there's at least one other account
with sufficient access to do the same (it just tends to vary by team
and origination timeframe). So, yes, probably easiest to give the
Infra team a list once it's been confirmed.
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 1, 2017 by Claudiu_Belu (1,200 points)   2
...