Skip to content
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.

Sign up for GitHub

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

Unpin versioningit version #196

Merged
merged 1 commit into from
Nov 16, 2023
Merged

Unpin versioningit version #196

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[build-system]
# Setuptools version should match setup.py; wheel because pip will insert it noisily
requires = ["setuptools >= 42.0.0", "versioningit ~= 0.3.0", "wheel"]
requires = ["setuptools >= 42.0.0", "versioningit", "wheel"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't it be

Suggested change
requires = ["setuptools >= 42.0.0", "versioningit", "wheel"]
requires = ["setuptools >= 42.0.0", "versioningit >= 0.3.0", "wheel"]

then so some pip env with outdated version would not just silently proceed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Projects with [build-system] tables should always be built in isolated environments with freshly-installed dependencies (e.g., via build). A "pip env with an outdated version" should have no effect.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then we should not have versioning limit on setuptools either (consistency is good) and why did we get it there in the first place?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

>= 42.0.0 just sets a lower bound (as opposed to ~= 0.3.0, which also sets an upper bound), so it's harmless.

why did we get it there in the first place?

Copy & paste from an earlier era. When setuptools v42.0.0 was new, I believe it was possible for isolated build environments to be created with an older setuptools version automatically installed (because venv and virtualenv both bundle setuptools instead of downloading the latest version every time an environment is created), so specifying a minimum setuptools version forced an update if the environment's version was older.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think that specifying meinimal compatible version when known is a matter of good habits etc, but since it is not generally followed (since typically we do not know what is a minimal version) -- I will not insist here. Let's proceed!

build-backend = 'setuptools.build_meta'

[tool.versioningit]
Expand All @@ -11,9 +11,9 @@ exclude = ["schema-*"]

[tool.versioningit.format]
# Same format as versioneer
distance = "{version}+{distance}.{vcs}{rev}"
dirty = "{version}+{distance}.{vcs}{rev}.dirty"
distance-dirty = "{version}+{distance}.{vcs}{rev}.dirty"
distance = "{base_version}+{distance}.{vcs}{rev}"
dirty = "{base_version}+{distance}.{vcs}{rev}.dirty"
distance-dirty = "{base_version}+{distance}.{vcs}{rev}.dirty"

[tool.versioningit.write]
file = "dandischema/_version.py"
Expand Down