replace custom version handling with setuptools-scm #1322
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dhellmann
force-pushed
the
switch-versioning-to-setuptools-scm
branch
2 times, most recently
from
e5967d0 to
ea3ddec
Compare
andy-neuma
reviewed
Apr 4, 2025
dhellmann
force-pushed
the
switch-versioning-to-setuptools-scm
branch
from
ea3ddec to
a3e45e1
Compare
dhuangnm
reviewed
Apr 4, 2025
dhellmann
force-pushed
the
switch-versioning-to-setuptools-scm
branch
from
a3e45e1 to
958a5d2
Compare
dhellmann
force-pushed
the
switch-versioning-to-setuptools-scm
branch
from
958a5d2 to
0adba4f
Compare
dbarbuzzi
previously approved these changes
Apr 8, 2025
brian-dellabetta
previously approved these changes
Apr 8, 2025
dhellmann
dismissed stale reviews from brian-dellabetta and dbarbuzzi
via
7611a63
dhellmann
force-pushed
the
switch-versioning-to-setuptools-scm
branch
from
0adba4f to
7611a63
Compare
|
How do I run that linter locally so I can check the formatting before pushing? |
@dhellmann you can use |
|
@dhellmann I just realized we need to update the Makefile as well according to the build changes. Can you please update it too? Thanks. |
What updates are needed there? |
dhellmann
force-pushed
the
switch-versioning-to-setuptools-scm
branch
from
7611a63 to
fc204fe
Compare
Nevermind, I figured it out as soon as I got set up to run |
|
I think this is ready for testing again, if someone could approve it, please. |
dhuangnm
reviewed
Apr 8, 2025
dhellmann
force-pushed
the
switch-versioning-to-setuptools-scm
branch
2 times, most recently
from
4c5558d to
8581008
Compare
dhuangnm
reviewed
Apr 9, 2025
dhellmann
force-pushed
the
switch-versioning-to-setuptools-scm
branch
from
8581008 to
32cd313
Compare
dhellmann
force-pushed
the
switch-versioning-to-setuptools-scm
branch
2 times, most recently
from
86b578f to
9717dce
Compare
|
I have fixed the linter issue and rebased, so need approval on the workflow to run the tests again. |
Use setuptools-scm to automatically compute a version based on the latest git tag. Remove the old logic for reading a static file to get the version string, but configure setuptools-scm to generate a similar file for anyone who wants to import it to get the version information. Replace the build_type value set in code with an environment variable so setup.py can continue to change the versioning scheme based on the type of build being performed. When the BUILD_TYPE is "nightly", produce an alpha release for the _next_ version, with the date as the alpha version. For example, when the most recent tag is 0.4.1 the nightly release version built on 3 Apr 2025 is 0.4.2a20250403. When the BUILD_TYPE is "release", if the commit being built has a tag use that tag's value as the version. When the BUILD_TYPE is "dev", or if the commit being built does not have a tag, or the git repository has pending changes, compute a development version combining the distance since the last tag with the expected next tag. For example, if the most recent tag is 0.4.1 and there have been 74 commits since that tag and the most recent commit SHA is 5e2c1c92, then the version would be 0.4.2.dev74+g5e2c1c92. If the local git repository has modified files that are not committed, the date is appended in the local version field, giving 0.4.2.dev74+g5e2c1c92.d20250403. When the BUILD_TYPE is "release", depend on the pinned version of compressed-tensors. Otherwise, let the version float so that dev and CI environments can control it. Signed-off-by: Doug Hellmann <[email protected]>
dhellmann
force-pushed
the
switch-versioning-to-setuptools-scm
branch
from
9717dce to
b0ea85f
Compare
dhuangnm
approved these changes
Apr 10, 2025
dsikka
approved these changes
Apr 10, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SUMMARY:
Use setuptools-scm to automatically compute a version based on the
latest git tag.
Remove the old logic for reading a static file to get the version
string, but configure setuptools-scm to generate a similar file for
anyone who wants to import it to get the version information.
Replace the build_type value set in code with an environment variable
so setup.py can continue to change the versioning scheme based on the
type of build being performed.
When the BUILD_TYPE is "nightly", produce an alpha release for the
next version, with the date as the alpha version. For example, when
the most recent tag is 0.4.1 the nightly release version built on 3
Apr 2025 is 0.4.2a20250403.
When the BUILD_TYPE is "release", if the commit being built has a tag
use that tag's value as the version.
When the BUILD_TYPE is "dev", or if the commit being built does not
have a tag, or the git repository has pending changes, compute a
development version combining the distance since the last tag with the
expected next tag. For example, if the most recent tag is 0.4.1 and
there have been 74 commits since that tag and the most recent commit
SHA is 5e2c1c92, then the version would be 0.4.2.dev74+g5e2c1c92. If
the local git repository has modified files that are not committed,
the date is appended in the local version field, giving
0.4.2.dev74+g5e2c1c92.d20250403.
TEST PLAN:
I tested this change locally using these commands
And using a variety of clean, dirty, and tagged commits.