Cannot reuse a deleted package name

[akatrevorjay]

Hi wonderful PyPA maintainers!

I created a package, tensorflow-detect, which has a rather strange requirement: it's version must match the tensorflow version it installs.

I initially uploaded this about a week ago, but quickly realized I had made a mistake, so I deleted the entire package and recreated it. I did this right after I initially uploaded it, and again today, but what I'm seeing is that I cannot upload a version I had previously uploaded, so now I'm stuck at v1.3.0 on the web interface, and cannot replace the broken versions I uploaded for the previous package (the one I deleted). They also do not show in the web interface, but those releases are still indexed and instalable as well:

https://pypi.org/manage/project/tensorflow-detect/releases/

May I (pretty please) request a one time full on deletion including previous releases?

I know why this is why it is, but if the versions do not match exactly, then the package's purpose is broken..

Thanks and sorry for the bother.
Trevor

[di]

Hi @akatrevorjay, apologies, but we can't make an exception here.

As such, I'm going to close this as a duplicate of #74 (which has much more discussion about why we have this policy).

That said, there is a bit of a workaround you can take advantage of here: since all the previous releases were .tar.gz source distributions, you can make .zip source distributions (only difference is the means of compression, they are otherwise interchangeable) which will be accepted as a distribution for the release (as the filename has not previously been used).

[akatrevorjay]

The zip workaround only works for non-wheel installs though, doesn't it?

[ncoghlan]

Note that if you make a <version>.postX release, all the installation tools will accept it as equivalent to <version>. If there's something tensorflow specific that isn't supporting post-releases properly, then that really needs to be fixed, since post-releases (and their equivalence behaviour) are a key part of meeting the otherwise conflicting requirements of not allowing the hashes of previously published artifacts to change, while also allowing folks to replace broken artifacts with fixed ones without having to bump the main version number.

[njsmith]

You say this was a one time request, but what's your plan going forward? Just "never make a mistake ever again"? That seems like a risky plan :-). The requirement that the version number match is very unusual; I can't think of a good reason for doing things that way, and it's not really how version numbers are designed to work. I'd try hard to find a way to get out of this requirement.

[akatrevorjay]

Correct, the code is done and tested, so it'll never be changed except for package renames ;)

On Sat, Aug 4, 2018, 2:50 AM Nathaniel J. Smith ***@***.***> wrote: You say this was a one time request, but what's your plan going forward? Just "never make a mistake ever again"? That seems like a risky plan :-). The requirement that the version number match is very unusual; I can't think of a good reason for doing things that way, and it's not really how version numbers are designed to work. I'd try hard to find a way to get out of this requirement. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQGIobxrict6641eQ9KSrcfmfmd81Bkks5uNW5cgaJpZM4VrkJ3> .

-- Ty, Trevor

[akatrevorjay]

Also, on version>.postX -- that's some fantastic into, but does it require the user to type that in when they install it? (Ie in a pip constraints/requirements file.) All that this package does is auto depend on tensorflow-gpu if you have cudas in your pkgconfig list, with a fallback to tensorflow. There isn't actually any code distributed with the package besides setup.py and a helper, lol.

On Mon, Aug 6, 2018, 10:44 AM Trevor Joynson ***@***.***> wrote: Correct, the code is done and tested, so it'll never be changed except for package renames ;) On Sat, Aug 4, 2018, 2:50 AM Nathaniel J. Smith ***@***.***> wrote: > You say this was a one time request, but what's your plan going forward? > Just "never make a mistake ever again"? That seems like a risky plan :-). > The requirement that the version number match is very unusual; I can't > think of a good reason for doing things that way, and it's not really how > version numbers are designed to work. I'd try hard to find a way to get out > of this requirement. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#188 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABQGIobxrict6641eQ9KSrcfmfmd81Bkks5uNW5cgaJpZM4VrkJ3> > . > -- Ty, Trevor

-- Ty, Trevor

[njsmith]

All that this package does is auto depend on tensorflow-gpu if you have cudas in your pkgconfig list, with a fallback to tensorflow.

Sounds like you're trying to do something pretty clever with python packaging tools here. You should talk to distutils-sig about what you're trying to do – maybe someone will have a better idea, or it might inform new changes in how python packaging works.

[akatrevorjay]

Yeah, it's super gross, but there's no better way afaik. I didn't want to rely on hardware interrogation since you may build something for another machine, so this way is what I believe to be a fair assumption since it at least works for all cases (except where you don't have cuda development headers installed, but you do have the libraries, but that's rather unheard of tbh)

…

On Mon, Aug 6, 2018, 12:15 PM Nathaniel J. Smith ***@***.***> wrote: All that this package does is auto depend on tensorflow-gpu if you have cudas in your pkgconfig list, with a fallback to tensorflow. Sounds like you're trying to do something pretty clever with python packaging tools here. You should talk to distutils-sig about what you're trying to do – maybe someone will have a better idea, or it might inform new changes in how python packaging works. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQGIgDzHNXYblYc7qSvvxUigX0odhrhks5uOJW8gaJpZM4VrkJ3> .

[njsmith]

there's no better way afaik

Right, that's why I'm suggesting explaining your problem and solution to distutils-sig, because the experts there will be able to tell you for sure if there's a better way, and if there isn't they might create one :-)

[akatrevorjay]

Nice. I'll do that.

…

On Mon, Aug 6, 2018, 1:05 PM Nathaniel J. Smith ***@***.***> wrote: there's no better way afaik Right, that's why I'm suggesting explaining your problem and solution to distutils-sig, because the experts there will be able to tell you for sure if there's a better way, and if there isn't they might create one :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQGIjHsqQlLnIDsixnXJ515zamKwt9Wks5uOKGNgaJpZM4VrkJ3> .

[ncoghlan]

An exact pin on == 1.1 will ignore the post release, but a compatible release check (~= 1.1) or a prefix match (== 1.1.*) will accept it.

Details at https://www.python.org/dev/peps/pep-0440/#version-matching

[merwok]

(Drive-by comment: thanks for the info about == X.Y.*, I was using ~= X.Y to achieve that and got surprised by tools matching X.Y+1. I think versioning specs think that Y+1 is compatible with Y but as a paranoid human I want to decide when I switch from X.4 to X.5!)

[njsmith]

@merwok This is a subtlety of the ~= operator actually (that also bit me this week!). Whatever version you give it, it assumes that you're ok with the last piece increasing, but not the others. So if you give it two pieces, like ~= 1.2, that accepts 1.2.0, 1.2.5, 1.3.0, ... but not 1.1 or 2.0. If you give it three pieces, like ~= 1.2.2, now it accepts 1.2.5, but not 1.3.0 or 1.2.0.

[akatrevorjay]

Can I request one other thing then perhaps?

My deleted releases are no longer linked with my package, but are still downloadable.

Could you (please) re-link those files with my package again by chance?

(I renamed the package in the middle of all of this thinking it was maybe a problem with the first package before hearing from you guys)

https://pypi.org/project/tensorflow-auto-detect-cpugpu/

(Missing ~15 releases that are still available and I cannot re-upload them)

Also, I appreciate the info. It wasn't too bad of a thing I renamed it as I got to change how it worked -- it no longer relies on development headers, instead interrogating your list of libraries per ldconfig, which works on minimal systems and even dynamic ld paths, so I'm happy about that part!