New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In pypi, it is impossible to reupload a removed file. #74

Open
Natim opened this Issue Sep 4, 2015 · 64 comments

Comments

Projects
None yet
@Natim

Natim commented Sep 4, 2015

HTTPError: 400 Client Error: This filename has previously been used, you should use a different version.
@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Sep 4, 2015

Also the previous version has been removed and is impossible to find.

Natim commented Sep 4, 2015

Also the previous version has been removed and is impossible to find.

@daenney

This comment has been minimized.

Show comment
Hide comment
@daenney

daenney Sep 4, 2015

It's probably still available in the Fastly caches, which is why you need to use a new filename. The old filename will have been marked as to cache indefinitely so even if you could upload a filename with the same name, if they had already fetched the old version they would never get the new one.

daenney commented Sep 4, 2015

It's probably still available in the Fastly caches, which is why you need to use a new filename. The old filename will have been marked as to cache indefinitely so even if you could upload a filename with the same name, if they had already fetched the old version they would never get the new one.

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Sep 4, 2015

In my case it isn't a problem because it is the exact same file.

Natim commented Sep 4, 2015

In my case it isn't a problem because it is the exact same file.

@hickford

This comment has been minimized.

Show comment
Hide comment
@hickford

hickford Sep 4, 2015

Contributor

See Donald's email at http://comments.gmane.org/gmane.comp.python.distutils.devel/22739

I've pushed changes to PyPI where it is no longer possible to reuse a filename and attempting to do it will give an 400 error "This filename has previously been used, you should use a different version."

Contributor

hickford commented Sep 4, 2015

See Donald's email at http://comments.gmane.org/gmane.comp.python.distutils.devel/22739

I've pushed changes to PyPI where it is no longer possible to reuse a filename and attempting to do it will give an 400 error "This filename has previously been used, you should use a different version."

@hickford

This comment has been minimized.

Show comment
Hide comment
@hickford

hickford Sep 4, 2015

Contributor

Npm did the same in 2014. See http://blog.npmjs.org/post/77758351673/no-more-npm-publish-f

While it is annoying to have to bump the version number for typos documentation changes, I believe in the long run, the benefits of greater reliability and data integrity are well worth it.

I presume the justification is the same for PyPI. It's an FAQ, so should probably go in documentation somewhere.

Contributor

hickford commented Sep 4, 2015

Npm did the same in 2014. See http://blog.npmjs.org/post/77758351673/no-more-npm-publish-f

While it is annoying to have to bump the version number for typos documentation changes, I believe in the long run, the benefits of greater reliability and data integrity are well worth it.

I presume the justification is the same for PyPI. It's an FAQ, so should probably go in documentation somewhere.

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Sep 4, 2015

Then we shouldn't allow people to remove their files if they cannot put them back.

Natim commented Sep 4, 2015

Then we shouldn't allow people to remove their files if they cannot put them back.

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Sep 4, 2015

I think we should allow to reupload the same removed file

Natim commented Sep 4, 2015

I think we should allow to reupload the same removed file

@tylerdave

This comment has been minimized.

Show comment
Hide comment
@tylerdave

tylerdave Sep 4, 2015

There are very good reasons for the current behavior. Authors should be able to delete for any number of reasons (legal, security, etc.) Users of the package should be able to rely on getting the exact same thing every time they install a package of a specific version.

If you delete a package that someone relies on, they know the version is gone and they need to make a change to fix it. If you could delete a package and replace it with something different but with the same version, it can break their program is any number of subtle ways and it would be very hard to determine the cause of the problem.

Allowing this would break the entire version number contract. You may have what seems to be a good reason to replace a version but allowing it is not worth making versions unreliable.

There are very good reasons for the current behavior. Authors should be able to delete for any number of reasons (legal, security, etc.) Users of the package should be able to rely on getting the exact same thing every time they install a package of a specific version.

If you delete a package that someone relies on, they know the version is gone and they need to make a change to fix it. If you could delete a package and replace it with something different but with the same version, it can break their program is any number of subtle ways and it would be very hard to determine the cause of the problem.

Allowing this would break the entire version number contract. You may have what seems to be a good reason to replace a version but allowing it is not worth making versions unreliable.

@hickford

This comment has been minimized.

Show comment
Hide comment
@hickford

hickford Sep 4, 2015

Contributor

Absolutely.

Contributor

hickford commented Sep 4, 2015

Absolutely.

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Sep 4, 2015

If you delete a package that someone relies on

You broke their package and you cannot put it back.

Natim commented Sep 4, 2015

If you delete a package that someone relies on

You broke their package and you cannot put it back.

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Sep 4, 2015

If you could delete a package and replace it with something different but with the same version, it can break their program

That's not what I am asking for.

I am asking for putting back the package I removed.

Natim commented Sep 4, 2015

If you could delete a package and replace it with something different but with the same version, it can break their program

That's not what I am asking for.

I am asking for putting back the package I removed.

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Sep 4, 2015

Allowing this would break the entire version number contract.

Allowing to put back the version you removed doesn't break any contracts. + You already have the previous package hash so you can check the version didn't change and that you are really re-uploading the file that you removed.

Natim commented Sep 4, 2015

Allowing this would break the entire version number contract.

Allowing to put back the version you removed doesn't break any contracts. + You already have the previous package hash so you can check the version didn't change and that you are really re-uploading the file that you removed.

@tylerdave

This comment has been minimized.

Show comment
Hide comment
@tylerdave

tylerdave Sep 4, 2015

There I agree. If it can be ensured via the hash that only the exact same package is uploaded to the same version then I don't see this being a problem in concept.

There I agree. If it can be ensured via the hash that only the exact same package is uploaded to the same version then I don't see this being a problem in concept.

@hickford

This comment has been minimized.

Show comment
Hide comment
@hickford

hickford Sep 4, 2015

Contributor

So long as the documentation and confirmation makes it clear that unpublishing is permanent, then I think it's reasonable and prudent.

It is generally considered bad behavior to remove versions of a library that others are depending on! Even if a package version is unpublished, that specific name and version combination can never be reused. In order to publish the package again, a new version number must be used.

https://docs.npmjs.com/cli/unpublish

Contributor

hickford commented Sep 4, 2015

So long as the documentation and confirmation makes it clear that unpublishing is permanent, then I think it's reasonable and prudent.

It is generally considered bad behavior to remove versions of a library that others are depending on! Even if a package version is unpublished, that specific name and version combination can never be reused. In order to publish the package again, a new version number must be used.

https://docs.npmjs.com/cli/unpublish

@hickford

This comment has been minimized.

Show comment
Hide comment
@hickford

hickford Sep 4, 2015

Contributor

To prevent malicious abuse, perhaps the policy should be strengthened to 'no uploads to old versions' #75

Contributor

hickford commented Sep 4, 2015

To prevent malicious abuse, perhaps the policy should be strengthened to 'no uploads to old versions' #75

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Sep 4, 2015

Member

Unless you have the physical file laying around still, it's unlikely you're going to have something that matches the same hash. The setup.py sdist command does not have deterministic output, each time you run it even if the code hasn't changed. This also means you can't use setup.py to upload the file, since setup.py will only let you upload a file that it has created in the currently executing command, not an already created file. That doesn't make it impossible to upload a file with the same hash, but it makes it tricky which suggests it's a bad UX to expect authors to have to navigate.

Most likely the eventual solution to this is that "delete" won't actually be a full out absolute deletion, it'll be more like a soft delete where it just acts as if it's deleted without actually deleting it (so it won't show up in the API, won't appear anywhere, etc) but there will be a list of these deleted things when the author logs in and a button that says "Restore" that allows them to restore a file they've previously deleted. Possibly this would have a periodic cleanup where if something was soft deleted for some period of time (a month? 6 months? a year?) we'll go through and clean it up and actually hard delete it then. Perhaps we'd also enable it for authors to trigger an immediate hard delete of something they've soft deleted, but there would be plenty of big warnings that if they press that button there is no recovery possible.

Member

dstufft commented Sep 4, 2015

Unless you have the physical file laying around still, it's unlikely you're going to have something that matches the same hash. The setup.py sdist command does not have deterministic output, each time you run it even if the code hasn't changed. This also means you can't use setup.py to upload the file, since setup.py will only let you upload a file that it has created in the currently executing command, not an already created file. That doesn't make it impossible to upload a file with the same hash, but it makes it tricky which suggests it's a bad UX to expect authors to have to navigate.

Most likely the eventual solution to this is that "delete" won't actually be a full out absolute deletion, it'll be more like a soft delete where it just acts as if it's deleted without actually deleting it (so it won't show up in the API, won't appear anywhere, etc) but there will be a list of these deleted things when the author logs in and a button that says "Restore" that allows them to restore a file they've previously deleted. Possibly this would have a periodic cleanup where if something was soft deleted for some period of time (a month? 6 months? a year?) we'll go through and clean it up and actually hard delete it then. Perhaps we'd also enable it for authors to trigger an immediate hard delete of something they've soft deleted, but there would be plenty of big warnings that if they press that button there is no recovery possible.

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Sep 4, 2015

That doesn't make it impossible to upload a file with the same hash, but it makes it tricky which suggests it's a bad UX to expect authors to have to navigate.

With twine it is as simple as:

twine upload cliquet-2.5.0-py2.py3-none.whl

Natim commented Sep 4, 2015

That doesn't make it impossible to upload a file with the same hash, but it makes it tricky which suggests it's a bad UX to expect authors to have to navigate.

With twine it is as simple as:

twine upload cliquet-2.5.0-py2.py3-none.whl
@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Sep 4, 2015

Member

Right, I wrote twine, but not everyone uses that so you have to explain to them that they have to use twine to be able to reupload not setup.py upload. In addition you have to explain to them they need the exact same file, not one created the same way. It's fiddly and people will get confused.

Member

dstufft commented Sep 4, 2015

Right, I wrote twine, but not everyone uses that so you have to explain to them that they have to use twine to be able to reupload not setup.py upload. In addition you have to explain to them they need the exact same file, not one created the same way. It's fiddly and people will get confused.

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Sep 4, 2015

People are not dumb, if they need to do something complicated they will eventually succeed. The fact is even if they know all the things, they won't be able to do it.

But yeah #75 is a workaround for now, (using .zip instead of .tar.gz for instance)

Natim commented Sep 4, 2015

People are not dumb, if they need to do something complicated they will eventually succeed. The fact is even if they know all the things, they won't be able to do it.

But yeah #75 is a workaround for now, (using .zip instead of .tar.gz for instance)

@domibarton

This comment has been minimized.

Show comment
Hide comment
@domibarton

domibarton Dec 27, 2015

As I already wrote it in #75

I think that behaviour is quite OK for the live repo.

Though, to be honest, it's a huge PITA for the test repo. I support integrity and all that stuff on "production" systems. However, developers need to have their code / packages checked somewhere and it's a PITA if you can't upload them same version twice while testing a new release.

There's no other way than the test repo to test your package. With git (or any other SCM) you can easily create a new branch and test it until you're sure everything works. Or if you've a look at PHP Packagist (compose) there's a -dev version for each development branch. On Docker the same, you can test your feature/release branches before tagging and going "live".

With the new policy you basically say: You've ONE SINGLE TRY and that one SHOULD WORK. No chance for a 2nd try. IMHO this isn't the purpose of a testing system and breaks the whole "we've a testing repo" idea. To be honest, I think this only leads to annoyed developers and a lot of "crippled versions" because developers couldn't properly test their versions before going live.

tl;dr:
I suppose you do that on the live system but not on the test system.

As I already wrote it in #75

I think that behaviour is quite OK for the live repo.

Though, to be honest, it's a huge PITA for the test repo. I support integrity and all that stuff on "production" systems. However, developers need to have their code / packages checked somewhere and it's a PITA if you can't upload them same version twice while testing a new release.

There's no other way than the test repo to test your package. With git (or any other SCM) you can easily create a new branch and test it until you're sure everything works. Or if you've a look at PHP Packagist (compose) there's a -dev version for each development branch. On Docker the same, you can test your feature/release branches before tagging and going "live".

With the new policy you basically say: You've ONE SINGLE TRY and that one SHOULD WORK. No chance for a 2nd try. IMHO this isn't the purpose of a testing system and breaks the whole "we've a testing repo" idea. To be honest, I think this only leads to annoyed developers and a lot of "crippled versions" because developers couldn't properly test their versions before going live.

tl;dr:
I suppose you do that on the live system but not on the test system.

@brianmay

This comment has been minimized.

Show comment
Hide comment
@brianmay

brianmay Mar 6, 2016

In my case, I forgot to sign the upload. It appears once you have uploaded the package it is impossible to fix any problems you made with the upload without making a new release. Even if you just want to upload the exact same version again.

brianmay commented Mar 6, 2016

In my case, I forgot to sign the upload. It appears once you have uploaded the package it is impossible to fix any problems you made with the upload without making a new release. Even if you just want to upload the exact same version again.

@daenney

This comment has been minimized.

Show comment
Hide comment
@daenney

daenney Mar 6, 2016

But how do you know it is "the exact same version"? Unless it checks the uploads are binary identical it would allow you to upload a totally different release with the same version which can cause any amount of problems.

daenney commented Mar 6, 2016

But how do you know it is "the exact same version"? Unless it checks the uploads are binary identical it would allow you to upload a totally different release with the same version which can cause any amount of problems.

@torarnv

This comment has been minimized.

Show comment
Hide comment
@torarnv

torarnv Mar 14, 2016

Just his what @domibarton is describing. What's the point of a test repo if you can't make mistakes?

torarnv commented Mar 14, 2016

Just his what @domibarton is describing. What's the point of a test repo if you can't make mistakes?

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Mar 14, 2016

Just his what @domibarton is describing. What's the point of a test repo if you can't make mistakes?

Why cannot you do package x.y.z.dev0 and then package x.y.z.dev1?

Natim commented Mar 14, 2016

Just his what @domibarton is describing. What's the point of a test repo if you can't make mistakes?

Why cannot you do package x.y.z.dev0 and then package x.y.z.dev1?

@torarnv

This comment has been minimized.

Show comment
Hide comment
@torarnv

torarnv Mar 14, 2016

I could, and then having to remember to wipe those temp changes from my working tree before pushing to the live pypi repo.

torarnv commented Mar 14, 2016

I could, and then having to remember to wipe those temp changes from my working tree before pushing to the live pypi repo.

@snare

This comment has been minimized.

Show comment
Hide comment
@snare

snare Apr 24, 2016

I uploaded a new version of Voltron yesterday and the server threw a 500 error during the upload. This resulted in a partial file being hosted as the current wheel for this package. The file size was smaller than my local one, and the hash differed.

This operation needs to be atomic. If the upload fails, you have no opportunity to try again. The only option is to use a different version number, which is not an appropriate solution.

IMO it should be a requirement that the hash of the upload is verified by the author before it is marked as "published".

snare commented Apr 24, 2016

I uploaded a new version of Voltron yesterday and the server threw a 500 error during the upload. This resulted in a partial file being hosted as the current wheel for this package. The file size was smaller than my local one, and the hash differed.

This operation needs to be atomic. If the upload fails, you have no opportunity to try again. The only option is to use a different version number, which is not an appropriate solution.

IMO it should be a requirement that the hash of the upload is verified by the author before it is marked as "published".

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Apr 25, 2016

Yes I have the same problem with my last uploaded packages.

Natim commented Apr 25, 2016

Yes I have the same problem with my last uploaded packages.

@niedakh

This comment has been minimized.

Show comment
Hide comment
@niedakh

niedakh Jun 3, 2016

My files were uploaded broken, due to a connection error, why can't I replace them?!

niedakh commented Jun 3, 2016

My files were uploaded broken, due to a connection error, why can't I replace them?!

@pstch

This comment has been minimized.

Show comment
Hide comment
@pstch

pstch Jun 13, 2016

I also suffer from this issue because of PyPI's recurrent HTTP 500 errors, which leads to incomplete uploads : the client errors out, but the file is created, which then makes it impossible to handle the intermittent upload error by simply retrying.

Having to bump version numbers just because of connection errors is quite annoying. Maybe the upload operation could be made atomic, so that it does not create a file unless everything completes normally (possibly by waiting for user confirmation).

pstch commented Jun 13, 2016

I also suffer from this issue because of PyPI's recurrent HTTP 500 errors, which leads to incomplete uploads : the client errors out, but the file is created, which then makes it impossible to handle the intermittent upload error by simply retrying.

Having to bump version numbers just because of connection errors is quite annoying. Maybe the upload operation could be made atomic, so that it does not create a file unless everything completes normally (possibly by waiting for user confirmation).

@dstufft

This comment has been minimized.

Show comment
Hide comment
@mikofski

This comment has been minimized.

Show comment
Hide comment
@mikofski

mikofski Jul 14, 2016

Just use the manual interface by going to your package pypi site and select files. Change the names of the wheels slightly and add a comment if desired. Then you can upload the replacements for the removed files. This worked fine for me.

Just use the manual interface by going to your package pypi site and select files. Change the names of the wheels slightly and add a comment if desired. Then you can upload the replacements for the removed files. This worked fine for me.

@brechtm

This comment has been minimized.

Show comment
Hide comment
@brechtm

brechtm Aug 10, 2016

Even after removing the project on TestPyPI, it is not possible to upload the same version.

It's probably a good idea to use devpi instead of (or in addition to) the TestPyPI server.

brechtm commented Aug 10, 2016

Even after removing the project on TestPyPI, it is not possible to upload the same version.

It's probably a good idea to use devpi instead of (or in addition to) the TestPyPI server.

@bittner

This comment has been minimized.

Show comment
Hide comment
@bittner

bittner Sep 1, 2016

Will this behavior stay the same forever? It's a bit painful.

I had a syntax error in the long description (so the reStructuredText didn't get converted), and instead of fixing it manually on PyPI I deleted the complete project and started from scratch. Should be the cleanest approach for a new package, shouldn't it?

Instead, now I look like an idiot: There is a version 0.1.0 of my package in the index, but I can't upload an installation package for it ever again. 😕

BTW, here is the same question/problem/answer on StackOverflow.

bittner commented Sep 1, 2016

Will this behavior stay the same forever? It's a bit painful.

I had a syntax error in the long description (so the reStructuredText didn't get converted), and instead of fixing it manually on PyPI I deleted the complete project and started from scratch. Should be the cleanest approach for a new package, shouldn't it?

Instead, now I look like an idiot: There is a version 0.1.0 of my package in the index, but I can't upload an installation package for it ever again. 😕

BTW, here is the same question/problem/answer on StackOverflow.

@Natim

This comment has been minimized.

Show comment
Hide comment
@Natim

Natim Sep 1, 2016

@bittner My bet is that you should probably consider this to be like that for ever and find another solution yes. This policy simplifies a lot the package caching and replication.

For the long description you can change it in the pypi admin. It doesn't fix it in the package but at least it fixes your problem.

You can also just create a new 0.1.1 patch release with it fixed.

Natim commented Sep 1, 2016

@bittner My bet is that you should probably consider this to be like that for ever and find another solution yes. This policy simplifies a lot the package caching and replication.

For the long description you can change it in the pypi admin. It doesn't fix it in the package but at least it fixes your problem.

You can also just create a new 0.1.1 patch release with it fixed.

@joernhees

This comment has been minimized.

Show comment
Hide comment
@joernhees

joernhees Jan 30, 2017

this is quite annoying... i just had a wheel for py2 pick up a build/src for py3 (that went through 2to3)... resulting ...-py2-none-any.whl is broken.

Considering that i noticed the problem within 2 minutes and immediately deleted the bogus .whl, it would be nice to have an option to pretend it just didn't happen. I see the arguments that releases should be immutable, but i'm quite sure that no one besides me pulled that file within the time-frame. As mistakes can and will happen, i'd love to not be robbed of a choice as a maintainer to decide what's best myself.

Why not at least have a grace period of a few minutes?

this is quite annoying... i just had a wheel for py2 pick up a build/src for py3 (that went through 2to3)... resulting ...-py2-none-any.whl is broken.

Considering that i noticed the problem within 2 minutes and immediately deleted the bogus .whl, it would be nice to have an option to pretend it just didn't happen. I see the arguments that releases should be immutable, but i'm quite sure that no one besides me pulled that file within the time-frame. As mistakes can and will happen, i'd love to not be robbed of a choice as a maintainer to decide what's best myself.

Why not at least have a grace period of a few minutes?

@dstufft

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Jan 30, 2017

Member

2 minutes is plenty of time for hundreds of mirroring clients that run on a one minute cron job to find the file and pull it down immediately.

Member

dstufft commented Jan 30, 2017

2 minutes is plenty of time for hundreds of mirroring clients that run on a one minute cron job to find the file and pull it down immediately.

joernhees added a commit to joernhees/pypi-legacy that referenced this issue Jan 30, 2017

confirm deleting release files
At the moment removed files cannot be uploaded again later.
This patch mitigates a UX hazard where a maintainer might expect they just re-upload the file later.
See pypa/packaging-problems#74
@joernhees

This comment has been minimized.

Show comment
Hide comment
@joernhees

joernhees Jan 30, 2017

mirroring clients as in pypi caches? they could and should update caches as well, no?

i have the feeling that pypi internal arguments are dictating maintainer experience here... why not give maintainers the information (like end-user download stats) to make well informed decisions and let them make their decisions?

at least however put a warning on that delete button on the pypi website as mentioned in #74 (comment) ... it's a big UX hazard that trips up maintainers and is luring in the interface for at least 1.5 years now.

mirroring clients as in pypi caches? they could and should update caches as well, no?

i have the feeling that pypi internal arguments are dictating maintainer experience here... why not give maintainers the information (like end-user download stats) to make well informed decisions and let them make their decisions?

at least however put a warning on that delete button on the pypi website as mentioned in #74 (comment) ... it's a big UX hazard that trips up maintainers and is luring in the interface for at least 1.5 years now.

dcolligan added a commit to dcolligan/ga4gh-schemas that referenced this issue Mar 14, 2017

@mike01 mike01 referenced this issue Mar 15, 2017

Closed

pip installer #23

tparks5 pushed a commit to tparks5/tor-stem that referenced this issue May 5, 2017

Stem release 1.5.1
Damnit PyPI, you cannot legitimately claim this isn't a bug. Long story short
if a file is improperly uploaded that version is left in an unfixable state,
forcing us to do a version bump.

  pypa/packaging-problems#74 (comment)

No changes to Stem here. Just bumping the version to get around their bug.

tparks5 pushed a commit to tparks5/tor-stem that referenced this issue May 5, 2017

Stem release 1.5.2
Release creation in PyPI is both error prone and unfixable. As such it's safest
if we have a scrap project to sanity check that things are working as intended
before permanently screwing up our package. Really silly we need to do this,
but that's life.

  pypa/packaging-problems#74 (comment)

Previously we made releases with 'python setup.py upload' but PyPI has broken
this by prohibiting non-SSL uploads. Twine now seems to be the only game in
town so updating our setup.py clauses with things we previously set via the
site. One caveat is that PyPI's bug tracker field evidently cannot be set
via the setup.py...

  https://stackoverflow.com/questions/14459828/how-to-set-bug-tracker-url-in-setup-py-script

Oh well. Close enough.

tparks5 pushed a commit to tparks5/tor-stem that referenced this issue May 5, 2017

Drop setup.py's provides clause
We just provided this metadata for completeness. Turns out we'd be better off
without it...

  pypa/packaging-problems#74 (comment)

nhandler added a commit to Yelp/task_processing that referenced this issue May 25, 2017

Temporarily bump up version to test pypi
We are getting affected by pypa/packaging-problems#74 and need to bump up the version number to test uploads
@joelmiller

This comment has been minimized.

Show comment
Hide comment
@joelmiller

joelmiller Jun 16, 2017

When you go to remove something, you get a warning message that it can't be undone. Could that warning be improved? Not only can it not be undone, but you will not be able to upload a replacement with the same name...

When you go to remove something, you get a warning message that it can't be undone. Could that warning be improved? Not only can it not be undone, but you will not be able to upload a replacement with the same name...

@atagar

This comment has been minimized.

Show comment
Hide comment
@atagar

atagar Jun 16, 2017

Yes, that's what's missing from the message. "Cannot be undone" means "cannot recover the deleted file" but it says nothing about it being impossible to re-upload another file.

Ideally the message would say something like "This cannot be undone and another file by the same name cannot be uploaded. This is a known limitation of PyPi and tracked on [link to issue]."

atagar commented Jun 16, 2017

Yes, that's what's missing from the message. "Cannot be undone" means "cannot recover the deleted file" but it says nothing about it being impossible to re-upload another file.

Ideally the message would say something like "This cannot be undone and another file by the same name cannot be uploaded. This is a known limitation of PyPi and tracked on [link to issue]."

@joernhees

This comment has been minimized.

Show comment
Hide comment
@joernhees

joernhees Jun 16, 2017

all that's missing is someone hitting a button here: pypa/pypi-legacy#591

all that's missing is someone hitting a button here: pypa/pypi-legacy#591

moelius added a commit to moelius/async-task-processor that referenced this issue Sep 12, 2017

@cdrage cdrage referenced this issue Sep 12, 2017

Closed

0.8.0 release #1214

jdavid added a commit to hforge/itools that referenced this issue Oct 21, 2017

@ulfmueller ulfmueller referenced this issue Dec 11, 2017

Closed

New release including upgrade to pypsa 0.11 #100

7 of 7 tasks complete

hubot pushed a commit to f-droid/fdroidserver that referenced this issue Feb 22, 2018

bump to 1.0.2 to placate pypi
I mistakenly uploaded the dist tarball to pypi without the PGP signature.
So I deleted the release, thinking I could reupload it.  It is not possible:
pypa/packaging-problems#74

So this is really just a bump so I can reupload to pypi.
@brainwane

This comment has been minimized.

Show comment
Hide comment
@brainwane

brainwane Mar 13, 2018

Member

Some updates for folks in this discussion:

pypa/pypi-legacy#591 was merged in June 2017.

See #75 (comment) for the ability to upload wheels for old releases, https://mail.python.org/pipermail/distutils-sig/2017-December/thread.html#31835 regarding immutability of metadata for past releases, and https://packaging.python.org/guides/using-testpypi/ for guidance on using the new Test PyPI.

Warehouse, the codebase behind the new PyPI, is available as a pre-production site at https://pypi.org, we're making steady progress on the developer roadmap thanks to funding from Mozilla's Open Source Support Program, and it's on its way to replacing the legacy PyPI site entirely within the next few months. We're currently seeking feedback from package maintainers about what does or doesn't work for you in the new interface, and in the next few weeks we'll be doing more outreach to the wider Python developer community. If you have tried the release deletion interface in Warehouse (including at https://test.pypi.org ) and the warning isn't strong enough, please let us know.

pypa/warehouse#726 is open to discuss how PyPI and Test PyPI can be better at providing staging/preview functionality for maintainers. #10 is open to discuss toolchain improvements for testing a package after creating it but before uploading it. There's an open issue pypa/twine#207 for adding a "dry run" option to Twine. (I am a new maintainer of Twine and just released Twine 1.10.0; please upgrade.) @atagar I saw your comment #74 (comment) and followed the wiki history to check your code -- have you switched to Twine, and if so, does the approach you used still work?

Hope this helps.

Member

brainwane commented Mar 13, 2018

Some updates for folks in this discussion:

pypa/pypi-legacy#591 was merged in June 2017.

See #75 (comment) for the ability to upload wheels for old releases, https://mail.python.org/pipermail/distutils-sig/2017-December/thread.html#31835 regarding immutability of metadata for past releases, and https://packaging.python.org/guides/using-testpypi/ for guidance on using the new Test PyPI.

Warehouse, the codebase behind the new PyPI, is available as a pre-production site at https://pypi.org, we're making steady progress on the developer roadmap thanks to funding from Mozilla's Open Source Support Program, and it's on its way to replacing the legacy PyPI site entirely within the next few months. We're currently seeking feedback from package maintainers about what does or doesn't work for you in the new interface, and in the next few weeks we'll be doing more outreach to the wider Python developer community. If you have tried the release deletion interface in Warehouse (including at https://test.pypi.org ) and the warning isn't strong enough, please let us know.

pypa/warehouse#726 is open to discuss how PyPI and Test PyPI can be better at providing staging/preview functionality for maintainers. #10 is open to discuss toolchain improvements for testing a package after creating it but before uploading it. There's an open issue pypa/twine#207 for adding a "dry run" option to Twine. (I am a new maintainer of Twine and just released Twine 1.10.0; please upgrade.) @atagar I saw your comment #74 (comment) and followed the wiki history to check your code -- have you switched to Twine, and if so, does the approach you used still work?

Hope this helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment