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

[Jeremy Stanley]

On 2017-09-29 17:31:10 +0200 (+0200), Thierry Carrez wrote:
> OK, I got individual PTL confirmation that it was OK to remove all of
> those from PyPI:
> 
> mistral-extra 2015.1.0
> mistral-dashboard 2015.1.*
> 
> networking-odl, 2015.1.1  2015.1.dev986
> 
> networking-midonet, 2014.2.2 and various 2015.1.* versions
> (might have been removed by networking-midonet folks by now)
> 
> sahara-image-elements 2014.*.*
> sahara-dashboard 2014.*.*

I finally got around to processing these deletions. And yes as far
as I can tell someone with access to the "midonet" account on PyPI
already took care of the networking-midonet cleanup, but I've
handled the others now.
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Thierry Carrez]

OK, I got individual PTL confirmation that it was OK to remove all of
those from PyPI:

mistral-extra 2015.1.0
mistral-dashboard 2015.1.*

networking-odl, 2015.1.1  2015.1.dev986

networking-midonet, 2014.2.2 and various 2015.1.* versions
(might have been removed by networking-midonet folks by now)

sahara-image-elements 2014.*.*
sahara-dashboard 2014.*.*

Cheers,

-- 
Thierry Carrez (ttx)

__
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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Renat Akhmerov]

I confirm that you can delete mistral versions with “2015”.

Thanks

Renat Akhmerov
@Nokia

On 15 Sep 2017, 23:58 +0700, Rong Zhu , wrote:
> +1 for murano-dashboard and murano-agent
>
> On Fri, Sep 1, 2017 at 1:51 AM, Thierry Carrez  wrote:
> > Claudiu Belu wrote:
> > > 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.
> > > [...]
> >
> > Yes, for a first batch I propose we clean up the following:
> >
> > python-congressclient 2015.1.0
> > python-congressclient 2015.1.0rc1
> > python-designateclient 2013.1.a8.g3a2a320
> > networking-hyperv 2015.1.0
> >
> > For the remaining (official) ones (mistral-extra, networking-odl,
> > murano-dashboard, networking-hyperv, networking-midonet,
> > sahara-image-elements, freezer-api, murano-agent, mistral-dashboard,
> > sahara-dashboard) let's wait until we can get PTL signoff.
> >
> > --
> > Thierry Carrez (ttx)
> >
> > __
> > 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
__
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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Rong Zhu]

+1 for murano-dashboard and murano-agent

On Fri, Sep 1, 2017 at 1:51 AM, Thierry Carrez  wrote:
> Claudiu Belu wrote:
>> 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.
>> [...]
>
> Yes, for a first batch I propose we clean up the following:
>
> python-congressclient 2015.1.0
> python-congressclient 2015.1.0rc1
> python-designateclient 2013.1.a8.g3a2a320
> networking-hyperv 2015.1.0
>
> For the remaining (official) ones (mistral-extra, networking-odl,
> murano-dashboard, networking-hyperv, networking-midonet,
> sahara-image-elements, freezer-api, murano-agent, mistral-dashboard,
> sahara-dashboard) let's wait until we can get PTL signoff.
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Jeremy Stanley]

On 2017-09-07 08:59:15 +0200 (+0200), Thierry Carrez wrote:
> Jeremy Stanley wrote:
> > On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote:
> > [...]
> >> Yes, for a first batch I propose we clean up the following:
> >>
> >> python-congressclient 2015.1.0
> >> python-congressclient 2015.1.0rc1
> >> python-designateclient 2013.1.a8.g3a2a320
> >> networking-hyperv 2015.1.0
> > [...]
> > 
> > Are we waiting for any confirmation on this, or does a week of
> > silence constitute tacit approval? Should I go ahead and delete
> > these from PyPI now?
> 
> Yes please.

I have removed the above releases from PyPI as requested. Releases
made through our CI builds can still be found on
https://tarballs.openstack.org/ if needed in the future, even if
deleted from PyPI.
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Thierry Carrez]

Jeremy Stanley wrote:
> On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote:
> [...]
>> Yes, for a first batch I propose we clean up the following:
>>
>> python-congressclient 2015.1.0
>> python-congressclient 2015.1.0rc1
>> python-designateclient 2013.1.a8.g3a2a320
>> networking-hyperv 2015.1.0
> [...]
> 
> Are we waiting for any confirmation on this, or does a week of
> silence constitute tacit approval? Should I go ahead and delete
> these from PyPI now?

Yes please.

-- 
Thierry Carrez (ttx)

__
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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Jeremy Stanley]

On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote:
[...]
> Yes, for a first batch I propose we clean up the following:
> 
> python-congressclient 2015.1.0
> python-congressclient 2015.1.0rc1
> python-designateclient 2013.1.a8.g3a2a320
> networking-hyperv 2015.1.0
[...]

Are we waiting for any confirmation on this, or does a week of
silence constitute tacit approval? Should I go ahead and delete
these from PyPI now?
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Claudiu Belu]

networking-hyperv is under the Winstackers governance [1], of which I am the 
PTL of, and you have my +1. :)

[1] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n4656


From: Thierry Carrez [thie...@openstack.org]
Sent: Friday, September 01, 2017 10:51 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [relmgt] Libraries published to pypi with .X.Z 
versions

Claudiu Belu wrote:
> 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.
> [...]

Yes, for a first batch I propose we clean up the following:

python-congressclient 2015.1.0
python-congressclient 2015.1.0rc1
python-designateclient 2013.1.a8.g3a2a320
networking-hyperv 2015.1.0

For the remaining (official) ones (mistral-extra, networking-odl,
murano-dashboard, networking-hyperv, networking-midonet,
sahara-image-elements, freezer-api, murano-agent, mistral-dashboard,
sahara-dashboard) let's wait until we can get PTL signoff.

--
Thierry Carrez (ttx)

__
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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Thierry Carrez]

Claudiu Belu wrote:
> 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.
> [...]

Yes, for a first batch I propose we clean up the following:

python-congressclient 2015.1.0
python-congressclient 2015.1.0rc1
python-designateclient 2013.1.a8.g3a2a320
networking-hyperv 2015.1.0

For the remaining (official) ones (mistral-extra, networking-odl,
murano-dashboard, networking-hyperv, networking-midonet,
sahara-image-elements, freezer-api, murano-agent, mistral-dashboard,
sahara-dashboard) let's wait until we can get PTL signoff.

-- 
Thierry Carrez (ttx)

__
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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Claudiu Belu]

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 [fu...@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 .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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jeremy Stanley]

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


signature.asc
Description: Digital 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Tony Breeds]

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.


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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Thierry Carrez]

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)



signature.asc
Description: OpenPGP digital 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Matthew Thode]

On 17-08-29 15:58:55, Jeremy Stanley wrote:
> 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

I almost mentioned that, but as you said, the barrier to entry there is
so high.

-- 
Matthew Thode


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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Tony Breeds]

On Tue, Aug 29, 2017 at 02:09:32PM +, 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:

uc_url=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 

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

[Jeremy Stanley]

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


signature.asc
Description: Digital 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Thierry Carrez]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jeremy Stanley]

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


signature.asc
Description: Digital 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Doug Hellmann]

Excerpts from Claudiu Belu's message of 2017-08-29 14:09:32 +:
> 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Matthew Thode]

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-requ...@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)


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

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

[Claudiu Belu]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev