Skip to content

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

Merged
merged 3 commits into from
Aug 5, 2022

Conversation

rpanderson
Copy link
Member

@rpanderson rpanderson commented Jun 27, 2020

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:

  • Requires 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).
  • Makes all setuptools_scm configuration declarative, using the [tools.setuptools_scm] section of pyproject.toml. This is per the preferred configuration of setuptools_scm, and no other declarative config is supported (e.g. setup.cfg) that allows the arguments of setuptools_scm.get_version() to be specified (e.g. version_scheme). Doing so requires using [toml] extras of setuptools_scm and setuptools>=42.
  • Omits the environment variables SCM_VERSION_SCHEME and SCM_LOCAL_SCHEME from the GitHub Actions workflow.

@@ -26,7 +26,7 @@ packages = find:
python_requires = >=3.6
install_requires =
importlib_metadata
setuptools_scm
setuptools_scm>=4.1.0
Copy link
Member Author

@rpanderson rpanderson Jun 27, 2020

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?

Copy link
Member

@chrisjbillington chrisjbillington Jul 15, 2020

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__.pys use it, and a build-time requirement (i.e. belongs in pyproject.toml) since our setup.pys 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.

@philipstarkey
Copy link
Member

philipstarkey commented Jun 27, 2020

Edit: wrote on the wrong PR!

@rpanderson rpanderson force-pushed the force-release-branch-semver branch from 82c5056 to a13fa2d Compare June 27, 2020 09:51
philipstarkey added a commit to philipstarkey/labscript-utils that referenced this pull request Oct 30, 2020
@philipstarkey philipstarkey self-assigned this Oct 31, 2020
philipstarkey added a commit to philipstarkey/labscript-utils that referenced this pull request Nov 2, 2020
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.
philipstarkey added a commit to labscript-suite/labscript-utils that referenced this pull request Nov 2, 2020
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.
@dihm
Copy link
Contributor

dihm commented Dec 18, 2021

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?

@dihm dihm mentioned this pull request Aug 5, 2022
@dihm dihm merged commit 25de67b into labscript-suite:master Aug 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy