Pipx: [packaging] pipx-0.15.1.2/src/pipx/.main.py.swp: Failed to restore metadata

Created on 26 Jan 2020  路  14Comments  路  Source: pipxproject/pipx

Looks like there's some swp file in the 0.15.1.2 released tar file that is causing errors with installing the homebrew package. I'll take a look next week but flagging here in case anyone any ideas:

https://github.com/Homebrew/homebrew-core/pull/48955
https://github.com/Homebrew/homebrew-core/pull/49062

bug

Most helpful comment

@itsayellow let me give that a shot- I didn't realize 0.15.1.3 had fixed the issue. thanks for debugging everyone!

All 14 comments

Thanks @AlJohri . btw, we're at 0.15.1.3 now

So .main.py.swp is a vim swapfile that is created whenever vim is editing a file (in this case when vim would be editing main.py).

There's no .main.py.swp in the 0.15.1.2 tagged repo, but when I download the tar.gz file from pypi.org , it IS in the version submitted to pypi. I'm guessing this is my fault, since I did the 0.15.1.2 release and I use vim.

This problem does not exist in 0.15.1.3 (no .swp files found).

It seems we need to re-submit 0.15.1.2 to pypi with the proper files. I'm not sure how to do that. Does anybody know how to overwrite pypi versions?

It seems you cannot fix an old pypi version. You can delete it, but you cannot upload a new version to replace the old one.
https://stackoverflow.com/questions/44517306/how-can-i-re-upload-package-to-pypi
https://github.com/pypa/packaging-problems/issues/74

@AlJohri , that file (.main.py.swp) is a mistake and should be deleted. If you can do (despite the difference with the pypi tar.gz) then that would be the solution.

Another question, since it is the only solution possible, is if we should delete the 0.15.1.2 version on pypi that has the bogus additional file.

One way to sort of amend this with the least disturbance is to issue a post release (i.e. 0.15.1.2.post1) with the same code as 0.15.1.2, but with the swap file removed. It is generally not a good idea to delete a release outright, but pushing a new release is the best to do until we get PEP 592 in PyPI.

So @uranusjr , would the idea be EXACTLY everything the same as the 0.15.1.2 release, just without the swap file? For example, I would not change any metadata or version info, I would leave all of that just saying "0.15.1.2"?

Maybe I'll re-phrase my question: Something would need to be changed to be "0.15.1.2.post1" before submitting to pypi. What would be the changes?

It鈥檚 probably easiest to change the version in setup.py and build from it. If you insist on modifying a pre-built dist (especially wheel), you鈥檒l need to change the version listed in dist metadata (e.g. dist-info), and the dist鈥檚 file name. This should be enough to make PyPI and Twine happy.

OK, I have a 0.15.1.2.post1 ready to submit to pypi. I tested it on test.pypi.org and everything seems to be the way I expect. The only change compared with 0.15.1.2 in the pipx repo is to hard-code "0.15.1.2.post1" in setup.py for version.

Is everybody happy with this solution? (Speak now, or I will upload to pypi... :smiley:) @AlJohri , can you make a homebrew formula for 0.15.1.2 that uses 0.15.1.2.post1 from pypi? Is that going to solve the issue for homebrew?

I'm going to tag @cs01 and ask the above question of him specifically.

TIL about "post" releases. At first I was thinking it sounded good, but after reflecting a little more I might prefer a new release of 0.15.1.3 since I don't know if a post release will introduce more confusion or uncertainty. The post release seems like it makes things a little less explicit, and is a rare release type AFAIK. The downside of a "post" version (in my mind) is potentially slightly more uncertainty and straying from the canonical release process. What is the downside to a minor version bump?


The root cause of this is that itsayellow is a vim user 馃槃 we are blanket including everything in src with the graft src line in MANIFEST.in (my bad I guess). We should selectively include things instead so we're not still vulnerable to this (the next release could be by an emacs user and we'll accidentally get an emacs dotfile).

Well that is a good point. Actually 0.15.1.3 is perfectly fine (it has no swp file). So if @AlJohri can just skip v0.15.1.2 and move on to 0.15.1.3 then maybe the question is moot?

@AlJohri, can you just post a 0.15.1.3 release and forget about 0.15.1.2 for homebrew?

@itsayellow let me give that a shot- I didn't realize 0.15.1.3 had fixed the issue. thanks for debugging everyone!

Any progress on the homebrew package @AlJohri ?

Was this page helpful?
0 / 5 - 0 ratings