8000 Stop using `smart_install_lib` in `setup.py` · Issue #1652 · ivre/ivre · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Stop using smart_install_lib in setup.py #1652

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

Jump to bottom
Open
stegayet opened this issue Sep 8, 2024 · 3 comments
Open

Stop using smart_install_lib in setup.py #1652

stegayet opened this issue Sep 8, 2024 · 3 comments

Comments

@stegayet
Copy link
Contributor
stegayet commented Sep 8, 2024 •
edited
Loading

This issue is part of #1650.

smart_install_lib is currently used to tag Git versions. As distutils' install_lib has no replacement in setuptools, smart_install_lib has to be replaced with something else. Possible options:

  • Make use of dynamic metadata which is capable of deriving the current project version directly from git, using setuptools-scm build backend plugin. It would look like the following in pyproject.toml:
[build-system]
requires = ["setuptools>=64", "setuptools_scm>=8"]
build-backend = "setuptools.build_meta"

[tool.setuptools_scm]
version_file = "ivre/VERSION"

Out of the box, default versioning scheme is the following vs current versioning scheme is the following if I'm not mistaken:

  • 1.2.3 when we have a Git tag
  • 1.2.3.devN when we have N revisions on top of 1.2.3 tag

We might be able to get the same versioning by settingsetuptools_scm.local_scheme to no-local-version.

Worst case scenario, we could use vendored copy and import install_data from setuptools._distutils.command.install_lib to buy time, however it will be an issue when we'll want to completely migrate from setup.py to pyproject.toml.
@p-l-
Copy link
Member
p-l- commented Oct 15, 2024

@stegayet we're not stuck to the current versioning scheme so I'd be OK to use default versioning. I just need this to be OK with package management tools (e.g., for AUR, Debian, etc.) but those tools could very well strip the version details if they have to. WDYT?

@stegayet
Copy link
Contributor Author

Can be an option, I'll try to get the same versioning scheme for now to not break any existing package management integrations, and fallback to default versioning scheme if I can't.

@gpotter2
Copy link
Contributor
gpotter2 commented Mar 7, 2025

@p-l- Just FYI, why we didn't use it for Scapy: https://github.com/secdev/scapy/blob/20a3468a1043108676219b3629c735c06fab181f/setup.py#L41-L53

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@p-l- @gpotter2 @stegayet
0