-
Notifications
You must be signed in to change notification settings - Fork 40
Force release-branch-semver version scheme of setuptools_scm #53
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
Force release-branch-semver version scheme of setuptools_scm #53
Conversation
@@ -26,7 +26,7 @@ packages = find: | |||
python_requires = >=3.6 | |||
install_requires = | |||
importlib_metadata | |||
setuptools_scm | |||
setuptools_scm>=4.1.0 |
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.
@chrisjbillington should this be here? I think it can be omitted since it is now specified in the build-system requirements of pyproject.toml. If it should stay, it then needs to be added to other projects (e.g labscript-devices) which do not have it in install_requires of setup.cfg. Also, shouldn't it only ever have been in setup_requires?
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.
Yep! It still needs to be there.
It's both a runtime requirement (i.e. belongs in install_requires
) since our __version__.py
s use it, and a build-time requirement (i.e. belongs in pyproject.toml
) since our setup.py
s use it.
Installing a pre-built wheel does not install its build-time requirements, and similarly, building a wheel does not install its run-time requirements. So it needs to be both in pyproject.toml
and setup_requires
.
pyproject.toml
supersedes setup_requires
, so nothing belongs in setup_requires
.
If it should stay, it then needs to be added to other projects (e.g labscript-devices) which do not have it in install_requires of setup.cfg
Yes, I think to be kosher each project should depend on it directly, rather than relying on it being installed due to being a transitive dependency.
Edit: wrote on the wrong PR! |
82c5056
to
a13fa2d
Compare
labscript-suite/labscript-suite#53 erroenously removed the env var that removed the local version (required for uploading to test PyPI). Contrary to my statements in labscript-suite#62, the packaging library does not seem to be a dependency of setuptools. Instead they have vendored it as an internal submodule. Rather than rely on that, packaging is now a dependency of labscript-utils directly.
commit 4581953 Merge: d6335b2 eaa13a0 Author: Phil Starkey <philipstarkey@users.noreply.github.com> Date: Mon Nov 2 16:27:23 2020 +1100 Merge pull request #72 from philipstarkey/feature/versions-module-docs Added API docs for versions submodule added in #65 commit eaa13a0 Author: Phil Starkey <philipstarkey@users.noreply.github.com> Date: Mon Nov 2 16:24:02 2020 +1100 Second attempt at fixing the missing site package functions. This time we explicitly mock the missing functions using a lambda that returns an empty version of whatever types the methods usually return (hard coded into conf.py) commit d6335b2 Merge: f1c0962 720003b Author: Phil Starkey <philipstarkey@users.noreply.github.com> Date: Mon Nov 2 15:58:56 2020 +1100 Merge pull request #73 from philipstarkey/bugfix/setuptools_scm Removes setuptools_scm configuration from pyproject.toml commit 720003b Author: Phil Starkey <philipstarkey@users.noreply.github.com> Date: Mon Nov 2 15:57:33 2020 +1100 Removes setuptools_scm configuration from pyproject.toml As such, I see no way to utilise pyproject.toml for these settings, and am reverting to using the configuration specified in setup.py (restored in #71) commit f1c0962 Merge: dce6ac8 fa2654c Author: Phil Starkey <philipstarkey@users.noreply.github.com> Date: Mon Nov 2 13:06:10 2020 +1100 Merge pull request #71 from philipstarkey/bugfix/setuptools_scm Bugfixes for the mistakes in #70 commit 83c6ded Author: Phil Starkey <philipstarkey@users.noreply.github.com> Date: Mon Nov 2 13:04:42 2020 +1100 Attempt to fix the site module issue on readthedocs. commit 2c433e2 Author: Phil Starkey <philipstarkey@users.noreply.github.com> Date: Mon Nov 2 12:51:48 2020 +1100 Added API docs for versions submodule added in #65 Formatted docstrings to match sphinx Doogle style and added rst file to docs to display them. commit fa2654c Author: Phil Starkey <philipstarkey@users.noreply.github.com> Date: Mon Nov 2 11:09:10 2020 +1100 Bugfixes for the mistakes in #70 labscript-suite/labscript-suite#53 erroenously removed the env var that removed the local version (required for uploading to test PyPI). Contrary to my statements in #62, the packaging library does not seem to be a dependency of setuptools. Instead they have vendored it as an internal submodule. Rather than rely on that, packaging is now a dependency of labscript-utils directly.
Hey @rpanderson, I'm looking to merge this to bring it in line with all the other repos, but it appears they have a slightly different implementation than what is in this PR. Should we still keep it as is or mirror the build workflow from the other repos? |
The release-branch-semver version scheme was added in setuptools_scm v4.1.0. We currently don't require this version of setuptools_scm, and the release-branch-semver scheme is only used if the environment variable
SCM_VERSION_SCHEME
is set to this value (e.g. during our CI build).This PR:
setuptools_scm>=4.1.0
and always uses release-branch-semver. This will ensure consistency between local editable installations and distributed versions (including those on Test PyPI).setuptools_scm.get_version()
to be specified (e.g.version_scheme
). Doing so requires using [toml] extras of setuptools_scm and setuptools>=42.SCM_VERSION_SCHEME
andSCM_LOCAL_SCHEME
from the GitHub Actions workflow.