hey folks, not sure if anyone here is actively working on the monopolist idea but we just had a small breakthrough on our side on the package versioning<>git ordering problem. one of my teams built a prototype tool that given a pants target, will emit a wheel with a sha-tagged version with an explicit version (passed by flag at build time) and we’re gaining lots of experience with this internally. one problem that has emerged is that the version ordering there is brittle to human error and needs to be explicitly managed (e.g. the publisher has to increment this manually to get sane ordering). so we started looking at PEP440 “date based release segments”, which appear to work well to keep things ~mostly aligned to the git history (mod sub-second commit collisions). this is the new version generation scheme we settled on for that tool - which is to generate the version from the commit timestamp and then append the sha as a local version identifier):

[omerta pants2wheel (master)]$ git show -s --date="format:%Y.%-m%d.%H%M%S" --format="%cd+%h" HEAD
2021.719.214135+f345b57c9c997

might be useful to get proper

--upgrade

and range pin behavior.

I guess the key constraint is what your goals with versioning are. I've seen a number of version systems and they all do different things. If you really want to automate server you need to get down to the AST. If you want to semi-automate it you can use meaningful commit messages (eg, put "chore" or "feat" in the commit message). If you just want a unique ID the commit hash is "fine", you might not need a number. If you want sequential releases based on a "lineage" of releases, dates work fine.

I think in an ideal world, there would be no concrete version (aside from the git sha or some other fingerprint mode - and the resolver would just understand the linearization of git). its only out of necessity of conforming to the existing pypa packaging paradigms that versions are needed at all. one thought I had was to propose a PEP upstream to extend the versioning behavior at that level to support this new scm-based versioning scheme. but yes for right now the idea is to get ~mostly-sane ordering so that users can rely on

pip install --upgrade

and range pins like

my_package<2021.719

to get linearized version behavior.