-
Notifications
You must be signed in to change notification settings - Fork 660
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
Change packaging toolkit to use setuptools-scm #1895
Change packaging toolkit to use setuptools-scm #1895
Conversation
09602d4
to
24342ef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic!
🚀 🚀 🚀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change scares the... out of me as it could break a lot and I do not see any business-case (bug) for replacing pbr with something else (like setuptools-scm + python code).
Before seeing such a change I would like to see a bug describing the issue, the proposed solution (not implementation), maybe even some discussions around what we want to fix.
Packaging is one of the most sensible areas and I personally do not want to see molecule installation failing even if someone is trying to install it on system with ancient packaging tools (pip/setuptools/...).
@ssbarnea Back to why CI is failing now: we are hitting pypa/pip#6264 now because you've enabled
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not convinced about the pbr broken being broken by design but I will neither defend it forever. As long we can make molecule-with-setuptools-scm work on all platforms where molecule would be used (without having to add extra documentation to ask people to "tune" their systems) I am ok with it.
The only thing I care is to keep molecule being easily installable and consumed, as wheel or from source, with or without a virtualenv. Maybe we could use tox-docker to validate package installation on multiple platforms? (or we could use an ansible playbook too).
Do we have a full list of all platforms which we can test this PR against? |
Without having a full list I think this makes sense:
On these it need testing with:
Checkpoints:
|
The multi-platform testing matrix would be useful for testing in any case, both for |
That's what I'm working on now. We'll have a shim emulating missing features, just like I did it for |
If you are suggesting more test jobs, they can be added to Travis to be run on cron or we can use other resources (like GitHub Actions) just for that. |
Yeah, I'm mainly suggesting that while more test jobs is a good idea, I don't think it's something that should block this pull request. |
Exactly. Let's please move this discussion off this PR and focus on supporting with reviews. |
4f15dcf
to
bf60fa0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔥
setup_requires=['pbr'] | ||
) | ||
|
||
ALL_STRING_TYPES = tuple(map(type, ('', b'', u''))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to note for others, this would all be very scary and signal some major maintenance headaches but it seems to be doing just fine over at https://github.com/ansible/ansible-lint/blob/master/setup.py! So, please take that into consideration when reviewing. Maybe this shim itself needs to be packaged up ... ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, you cannot package this shim. Just because of a chicken/egg problem :)
Of course, you could do even more nasty stuff but I urge you not to.
The right thing to do is to actually upgrade pip/setuptools/python to something better maintainable and if future you can even expect something as magical as https://twitter.com/webKnjaZ/status/1113530472808763394
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
** But I was thinking about making a repo with an example like this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, and this version is way more improved over the one used in ansible-lint...
f1d9cda
to
13667c4
Compare
FTR: interesting things about compat — https://python3statement.org/practicalities/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
I haven't done any manual testing of this but it looks good to me now! I know that this has the possibility to resolve a number of issues for the package (and also to push forward re-release 2.20.0 -> 2.20, right!?), so am happy to see this move forward.
This comment has been minimized.
This comment has been minimized.
Please fix linting as it does make no sense to review code that does not pass CI. I do not see master as failing and I was not able to replicate any yapf related issue with master code (even with latest 0.26). Feel free to make a preparatory change related to yapf, if needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fails CI
0.26 is not the latest, 0.27 is. I was able to reproduce the failures on master:
The fixes to this don't belong in this PR, imo. |
13667c4
to
33fa9eb
Compare
33fa9eb
to
cb04425
Compare
Nope. I'm not raising the number of changed files from 12 to 100 here. Sorry. As per explanation @ #1891 I refuse to do non-atomic changes. |
a813237
to
9a58ecc
Compare
Also: * 🎨 include a shim to simulate setuptools' ability to read data from ``setup.cfg`` under ancient envs. * ⬆️ BSpecify project stability in metadata properly * ⬆️ Bump required tox to v3.8.4 * 🎨 Retrieve Molecule version using pkg_resources * 🐛 Whitelist find in tox in build-dists * 🎨 Enable isolated build in tox * 🔥 Drop Ansible 2.4 factor ref from tox * ⬆️ Bump setuptools req to v41.0.0 * 🎨 Wire up tox build-dists env into Travis CI * 🔒 Close ansible#1753 by using package_data Co-Authored-By: webknjaz <wk.cvs.github@sydorenko.org.ua>
9a58ecc
to
418459f
Compare
It seems like everyone who wanted to comment on this change already did it. So I'm merging it with red CI because master is broken and this change doesn't bring it new failures. |
Great. |
Migrate to setuptools-scm and setup.py. This follows on the back of ansible/molecule#1895. There are so many different standards for specifying Python dependencies so we are just going to pick one and stick with it. All runtime dependencies should be specified in setup.cfg. All test dependencies should be specified in tox.ini. Since we are using Tox as our test execution environment we can simply pin dependencies here.
PR Type