#TIL when creating a python project, and using some==2.2.0 to "pin" your requirements isn't actually pinning them, as the package owner (or anyone with access) may upload version 2.2.0-1, 2.2.0-2, etc. which will match the "==2.2.0".
@fohrloop Huh. I did a quick experiment which suggests otherwise:
>>> from packaging.version import Version
>>> from packaging.specifiers import SpecifierSet
>>> s1 = SpecifierSet("==2.2.0")
>>> Version("2.2.0.post0") in s1
False
>>> Version("2.2.0.post1") in s1
False
>>> Version("2.2.0") in s1
True
(".post0" is the canonical way of writing "-0", and so on)
@diazona Or are the --build-number=1 and ".post1" also the same thing? For some reason pip installs the wheel with version "2.2.0-1" instead of "2.2.0" if that's available, even if you specify "package==2.2.0".
So yeah, this is confusing: you can actually have a version 2.2.0-1, which is equivalent to 2.2.0.post1, and if that were the case, pip would be able to tell the difference. But the 2.2.0-1 mentioned in the video and your original toot is not a version, it's a part of the wheel filename, and it actually means version 2.2.0 with build tag 1, which is something different.
@hugovk@fohrloop Yeah I think that was mentioned somewhere earlier, but personally I'd rather just use a separate post release to solve that problem. IMO it's too unintuitive that you can install the same version of a package on the same system and get different code.
I wonder if the build tags are the way to go if you use readthedocs and want to just update the documentation. Or would you rather move the git tag and force rebuild in ReadTheDocs..?
@fohrloop@diazona Read the Docs points to Git tags, not wheel build tags. Changing a wheel build tag on a release artifact doesn't change the code, and so won't trigger an RTD build.
You might want to point people to the /latest/ RTD page instead of a /stable/.
@fohrloop@hugovk Oh I was assuming that /latest/ points to the documentation of the last commit on your main development branch, while /stable/ points to the documentation of the latest released version (i.e. with a version number). So, people who download the project from /pypi/ will more likely want the /stable/ version.
@hugovk @diazona
For docs-only-change (typo, link fix, etc.) for version X.Y.Z I have just checked out with the git tag X.Y.Z, made changes, and moved the git tag X.Y.Z to the new commit, and forced doc rebuild for git tag X.Y.Z in the RTD web ui. But seems that giving the new commit tag X.Y.Z.post1 would be a better way. I wonder if that's still shown as X.Y.Z in RTD for the users..?
@fohrloop@hugovk For a very small project this can work okay, but only if you change the tag quickly enough that nobody notices. In general, I think a better approach is to use release candidates: when you think you're ready to make a release, prepare it as an rc first and then after you've given yourself and others time to check it for possible issues, then retag the rc as the final version and release that. Then it should be quite rare that you need to change something after making the final release without incrementing the version number. But in the rare instances where you do, then I think having it show up as X.Y.Z.post1 in RTD is fine.
@diazona@fohrloop Yep, moving Git tags can cause confusion for others.
For CPython releases, the tag is made on the release manager's fork, and only pushed upstream once the release is ready, to avoid the whole world seeing a tag and thinking a new release is out.
There may be unforeseen build problems that delay the release for a few days!
# Make sure you are pushing to your GitHub fork, *not* to the main
@diazona@fohrloop
There's a balance: if you have ~50 wheels, and just one needs updating, you may not want to ping everyone with a "new" release because a single wheel has been fixed for OS X 10.9 (EOL in 2016).
With @pillow, it uses a total of 1 day and 9.5 hours CI time to build all the wheels!
Plus we used to have to wait for someone on the other side of the world for Windows wheels.
See my comment here, and the discussion is about restricting this sort of thing:
The really slow bit is the QEMU-emulated part, cross-compiling stuff on a different architecture. But it means we don't need to use Travis CI any more, and this whole thing is automated including publishing sdist+wheels to PyPI at the end.
At least that's the plan! This is our first release using cibuildwheel + Trusted Publishers automation! 🤞
@hugovk@fohrloop Well... I acknowledge your point, but given the way things are moving toward reproducibility these days, I think it's really valuable to have a deterministic mapping between (package, version, system) and wheel. That is, given the constraint that I want to install a particular version of a particular package on a particular system, there should be one specific wheel file that will be used for that particular installation. If a wheel file is broken or something, then I think making a new version needs to be the price of fixing that. (If that involves pinging people in some way that's annoying, then I would say it's the notification system that should be fixed.)
Add comment