setuptools_scm #93
Merged
setuptools_scm #93
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
Codecov Report
@@ Coverage Diff @@
## main #93 +/- ##
==========================================
- Coverage 87.15% 86.59% -0.57%
==========================================
Files 4 4
Lines 366 388 +22
==========================================
+ Hits 319 336 +17
- Misses 47 52 +5 |
Not absolutely necessary, just so it gets the right version in the tests. Also, add setuptools_scm to the release yaml. However, probably not necessary, as the test yaml does not have it explicitely listed but it is installed anyway.
|
I'm in favor of this and not having release branches |
Merged
|
Let's bring this in and see how it goes. |
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.
This PR is mainly meant for discussion. These would be the changes required to change to
setuptools_scm.The advantage of this approach is that you never have to hard-code a version any longer. The version numbers are created when installing it (e.g.,
pip install -e .or similar) and placed inscooby/version.py.Example of version numbers:
If scooby is not properly installed, e.g., the folder is copied somewhere without the
.git/-information, then the version will be unknown plus date:unknown-20220727.If you don't like this approach we can close this PR again.
Either way, I just found out that this setup does not seem to work with the release-branch setup that was implemented in #90 - because installing it now results in a version number
v0.5.13.dev..., so it does not recognize the tagReleases/v0.6.0. This means, if we want to use this we would either have to revert the release branches approach, or adjust my implementation here. As in this approach there are never two commits with identical version numbers, I think we could simply get rid of the release branches again.Edit: To support release branches, we have to add
to the
use_scm_version-dict insetup.py. But I guess first we decide if we keep release branches or not.There is one oddity that you might see when looking through the changes:
MANIFEST.inis normally used to include files.setuptools_scmreverts that, so everything is included by default, andMANIFEST.inis used to exclude files.TODO
setuptools_scmtorequirements: host:.