Skip to content
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

Pip wheel for pyyaml contains pyc files #527

Closed
det opened this issue Jun 16, 2021 · 3 comments
Closed

Pip wheel for pyyaml contains pyc files #527

det opened this issue Jun 16, 2021 · 3 comments
Assignees

Comments

@det
Copy link

det commented Jun 16, 2021

The pip wheel for pyyaml 5.4.1 contains .pyc files. An example is yaml/__pycache__/resolver.cpython-39.pyc. No other wheel pulled in for my project contains .pyc files.

These files are not supposed to be included in the wheel. Pip will compile pyc files for you during installation if you want them. I only noticed this because it is causing problems with Bazel's rules_python and I had to temporarily downgrade to an older version of pyyaml.

Thank you!

@nitzmahone
Copy link
Member

Thanks for the heads-up; that's definitely an oversight that we'll correct and get a finished artifact test in place for.

@nitzmahone nitzmahone self-assigned this Jun 17, 2021
@nitzmahone
Copy link
Member

This one took some gnarly debugging and a lot longer to figure out than it should've. Initially it seemed like a simple addition of a global-exclude to MANIFEST.in should've done the trick, but it didn't. It also didn't seem necessary- I've never run into cached bytecode issues while packaging other projects. The underlying problem is that a couple of the ancient customized distutils commands in setup.py actually import and run code from the intermediate build directory. Distutils/setuptools are internally pretty careful to prevent generation of cached bytecode files unless they're asked to, but the customized commands are not. Since the MANIFEST.in stage is only used during the initial install copy from the source tree into the build directory, and the build internals will reuse the intermediate outputs so long as the tracked files match the source, anything that appears in the build directory after that will end up getting copied to the finished wheels.

The ultimate solution here is probably to just get rid of as much of the custom command behavior entirely (test seems to be the most egregious offender). It's a lot less relevant in a PEP517 world, and doing so on a major release boundary should minimize impacts to packagers. Shorter-term for the the 5.x series, the existing test command can probably be augmented to run from an ephemeral copy of the build dir instead of in-place to prevent tainting the install source used for the wheel generation.

Thanks for reporting this.

@nitzmahone
Copy link
Member

This was fixed in 6.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@det @nitzmahone and others