-
Notifications
You must be signed in to change notification settings - Fork 754
pypi distfile with wrong permissions. #548
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
Comments
@petrrr you're going to need to be significantly more descriptive. As it exists in the repository, pycodestyle.py has 0o755 permissions. When I do |
Further if I do |
If I download the file pycodestyle-2.0.0.tar.gz and use tar i get the following:
To what I understood this usually happens when the umask of the releaser is set to restrictively. The problem with this is that default installation procedures may fail and needs some patching. |
Do you mean that you think something is wrong with the computer that @IanLee1521 created the release from? Do you know what he needs to do to fix this problem? |
Hmm, that does seem weird and incorrect.. I had used |
@IanLee1521 |
@IanLee1521 what OS do you use again? |
Built this on OS X. My default umask is 007, so I can rebuild a new sdist with 002 instead if folks think that will address things. |
Yes, I am on OSX, but I recall that on Linux tar behaves the same. I am using Macports to manages most python packages except for development and MacPorts uses the |
@IanLee1521 that umask (or 022) is probably good to set globally. There's a way to set it with launchctl. |
Yeah, I do that umask on purpose, but I will make a not to change that when I run setup.py sdist in the future. What do folks feel is the right way to handle fixing pypi? Would it be reasonable to simply upload the same version with the fixed umask, or does there need to be a version bump for fixing the uploaded tar ball? I'd rather the former myself, not sure if there are other considerations I'm not thinking of though. It would be the same files, just with the different umask. |
@IanLee1521: No, please avoid any stealth updates. Stealth update cause big issues to packaging projects (I am talking here for example for MacPorts) and to whoever mirrors tarballs for any reason. There is no clear trigger for any changes/updates to take place, the name does not change but the checksum does. You also risk that both versions coexist on the net. So if you update the tarball, please always bump the version as well. Anyway, if you want to avoid doing this immediately, at least from my perspective. you could correct permissions in the next release. I am now patching permissions for Macports. Still other might step into the same issue. |
PyPI does not allow for you to replace the file with the same version, so you best create a new release. A 2.0.1/2.1.0 is needed anyway because of #550. May as well just roll them all into a new version |
The currently available distfile for pycodestyle has permission no read permissions for world, which cases installation and runtime issues on some systems.
The text was updated successfully, but these errors were encountered: