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

Cheroot 5.9.1 has invalid files #61

Closed
jaraco opened this Issue Nov 23, 2017 · 14 comments

Comments

Projects
None yet
2 participants
@jaraco
Member

jaraco commented Nov 23, 2017

Yegor Y. sent me an e-mail reporting an issue with the cheroot 5.9.1 package. It contains invalid files like "test_core_BACKUP_1440.py". These files cause issues in compilation.

These files were not intended to be in the distribution. They happened to be on my machine when I cut the release manually. I cut the release manually because the CI process takes half an eternity to complete.

I'll cut a new 5.9.2 release to correct the issue.

jaraco added a commit that referenced this issue Nov 23, 2017

@jaraco

This comment has been minimized.

Member

jaraco commented Nov 23, 2017

I've cut a new release (two actually), but it hasn't gone out yet due to #63 and #64.

@jaraco

This comment has been minimized.

Member

jaraco commented Nov 23, 2017

Fixed in subsequent releases.

@jaraco jaraco closed this Nov 23, 2017

@webknjaz

This comment has been minimized.

Member

webknjaz commented Nov 24, 2017

@jaraco let's integrate setuptools-git to avoid messing around MANIFEST.in

@webknjaz webknjaz reopened this Nov 24, 2017

@jaraco

This comment has been minimized.

Member

jaraco commented Nov 24, 2017

We’re using setuptools_scm. Manifest.in isn’t there or if it is, it can be removed. The reason the files appeared was because they were on my machine when I built a manual release... and distutils picks up all .py files regardless of the finders or manifest.in. I don’t think there’s more to be done here.

@webknjaz

This comment has been minimized.

Member

webknjaz commented Dec 4, 2017

@jaraco AFAIK setuptools-scm only provides a way to look-up dist version, but not a list of files.

@webknjaz

This comment has been minimized.

Member

webknjaz commented Dec 4, 2017

I've re-checked with https://github.com/pypa/setuptools_scm and didn't find anything mentioning that it provides any integration for tracking files.

@webknjaz

This comment has been minimized.

Member

webknjaz commented Dec 4, 2017

https://github.com/msabramo/setuptools-git on the other hand provides such integration. It would tell setuptools to not include untracked files.

@jaraco

This comment has been minimized.

Member

jaraco commented Dec 5, 2017

setuptools_scm implements file finders and is the tool supported and endorsed by the PyPA for facilitating file finding an version inference for git and Mercurial repos. It's what I've been using on every project I maintain ever since I merged hgtools, a derivative of setuptools_hg, with setuptools_scm.

Unless you can illustrate something that setuptools-git does that setuptools_scm doesn't do and can'd do readily, then I'd much prefer to stick to setuptools_scm.

@jaraco jaraco closed this Dec 5, 2017

@webknjaz

This comment has been minimized.

Member

webknjaz commented Dec 5, 2017

@jaraco Okay, now I see. But if file finder only adds git-tracked files does this mean that you unintentionally git added that file?
My point is that none of untracked files should be recognised/added during the dist creation.

@jaraco

This comment has been minimized.

Member

jaraco commented Dec 5, 2017

Ahh. No - the files were never git added. The reason they appeared in the dist is because even if file finders are used, distutils always includes all .py files, regardless of what the manifest or file finders include.

@jaraco

This comment has been minimized.

Member

jaraco commented Dec 5, 2017

I thought I'd test my theory, but I failed (blah.py never gets included). Now I'm unsure how those files got included, and I think this issue deserves a good explanation.

@jaraco jaraco reopened this Dec 5, 2017

@jaraco

This comment has been minimized.

Member

jaraco commented Dec 5, 2017

Aha. So those files would have been pulled in (by distutils) because they are .py files and because they're in a package:

$ tree
.
├── cheroot
│   ├── __init__.py
│   └── test
│       ├── __init__.py
│       └── test_core_backup.py
└── setup.py

2 directories, 4 files
$ cat setup.py
__import__('distutils.core').core.setup(name='foo', version='1.0', packages=['cheroot', 'cheroot.test'])
$ python setup.py sdist 2> /dev/null | grep backup             
hard linking cheroot/test/test_core_backup.py -> foo-1.0/cheroot/test

@jaraco jaraco closed this Dec 5, 2017

@webknjaz

This comment has been minimized.

Member

webknjaz commented Dec 6, 2017

Fair enough. If you'll have any ideas on how to avoid this I'd like to implement smth to protect us from such accidents :)

@jaraco

This comment has been minimized.

Member

jaraco commented Dec 11, 2017

Well, the main way to avoid it is to always cut releases in CI, which is the recommended procedure. So making the automated release process nimble and fast should largely obviate this issue.

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