Cannot install ply 3.5 via pip

[virtuald]

Error message is:

$ pip install ply==3.5
Collecting ply==3.5
  Could not find a version that satisfies the requirement ply==3.5 (from versions: 3.4)
  Some externally hosted files were ignored as access to them may be unreliable (use --allow-external ply to allow).
  No matching distribution found for ply==3.5

[dabeaz]

Fixed. Removed from PyPI entirely.

[refi64]

@dabeaz Why?

[dabeaz]

The whole PyPI record for PLY-3.5 is completed wrecked. I've removed it. I have no idea when or if it can even be repaired. Sorry.

[virtuald]

Are you using python setup.py sdist upload to upload the files? I've never had a problem when uploading to pypi that way.

[dabeaz]

Doesn't work. Claims that the filename is in use.

Creating tar archive
removing 'ply-3.5' (and everything under it)
running upload
Submitting dist/ply-3.5.tar.gz to http://pypi.python.org/pypi
Upload failed (400): This filename has previously been used, you should use a different version.

Oh well. No PLY for PyPI.

[virtuald]

Strange. If you were uploading the files a different way, perhaps it's a bug in pypi so it still has the file cached somewhere. Or maybe the file was associated with a previous release on accident? It doesn't show up in the simple index though (https://pypi.python.org/simple/ply/).

Would recommend contacting the pypi admins then, it would be a shame if we weren't able to install it easily via pip. Looks like you can do so via http://sourceforge.net/p/pypi/support-requests/

[dabeaz]

I don't have the time to go chase down some bizarre PyPI issue on this. Will leave PLY-3.5 hosted on the PLY website for a little while for people to try if they want. Will roll a PLY-3.6 release in a week or so (and hope that ply-3.6.tar.gz is actually available).

[dstufft]

Puts on PyPI Maintainer Hat

So the reason you get the error message "This filename has previously been usd, you should use a different version" is because once you upload a file PyPI doesn't let you re-upload that same file (even with a different name). This is to prevent people from silently changing what a version means long after it's been released.

As to what caused the issue to begin with, I'm not sure since I can't see what state 3.5 was in now that it's been deleted. If you get PyPI in a weird state for 3.6 I'd love it if you could ping me before deleting it so I can take a look and figure out what happened and figure it out.

[johnyf]

For uploading ply v3.5 again, without running into problems with the memory of PyPI of a previous binary, a post0 could be appended to the version, as described in PEP 440.

Also, uploading to testPyPI before can diagnose whether it will work (though testPyPI behaves exactly like PyPI, in that it doesn't allow re-uploading a binary for a given version).

#206 is the relevant issue of PyPI describing the change that prevented re-uploading.

[virtuald]

@dstufft unless I misunderstood, I believe he ran the sdist upload after deleting the 3.5 release, which would imply that the pypi ply project is currently in a weird state. It is possible that he ran the command before deleting the release, as that isn't explicitly stated in the comments above.

[dabeaz]

No. I re-registered the project from scratch, tried the upload again and it was still failing. I then gave up and just deleted the whole PLY-3.5 release. Will worry about this issue later.

[virtuald]

In that case then python setup.py sdist upload should work now for 3.5.

[dabeaz]

Nope. It doesn't. I already tried the "delete the whole release and start over" approach and it failed.

[johnyf]

python setup.py sdist upload will not work, as described in #206 linked above. The reason is that PyPI now remembers the mapping from versions of uploaded archives to their hash values, even if the archives are deleted by the user, and even if the user deletes the whole PyPI entry.

[virtuald]

Oh interesting, I had done it as recently as a few months ago, but obviously this has changed since then.