Skip to content

Add a mechanism to programmatically determine live version from repo only when in an editable install #703

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

Open
GDYendell opened this issue Apr 11, 2022 · 2 comments

Comments

@GDYendell
Copy link

GDYendell commented Apr 11, 2022

I am trying to implement a way to get the runtime version if editable and the install version otherwise (as mentioned in #143). I initially thought we could try to import the generated _version.py and if it doesn't exist use setuptools_scm.get_version, e.g.

try:
    from ._version import version as __version__
except ImportError:
    from setuptools_scm import get_version
    __version__ = get_version()

but _version.py is created in the source tree for editable installs, so the first import always works. I have tested adding the following develop hook to setup.py, so at the end of an editable install it just removes the _version.py

import os
from pathlib import Path

from setuptools import setup
from setuptools.command.develop import develop


class Develop(develop):
    def install_for_development(self):
        develop.install_for_development(self)
        version_path = Path(self.egg_path) / "pvi/_version.py"
        os.remove(version_path)


setup(
    use_scm_version={
        "write_to": "src/pvi/_version.py",
    },
    setup_requires=["setuptools_scm"],
    cmdclass=dict(develop=Develop)
)

which works - it uses the live version for an editable install, but can find _version.py and use that otherwise. But, is there a better way to do this? Could this develop build hook to delete the file be added within setuptools_scm, optionally (or the logic to create it be moved to a hook that doesn't run for editable installs)?

@RonnyPfannschmidt
Copy link
Contributor

Currently all proposed ways (not just yours) integrate badly and leave packages with wrong/mismatched Metadata

My next goal is integration with hatchery and editable tooling for that

I don't have the bandwidth for a correct setuptools version myself and would like to avoid having years of a half-assed solution

1 similar comment
@RonnyPfannschmidt
Copy link
Contributor

Currently all proposed ways (not just yours) integrate badly and leave packages with wrong/mismatched Metadata

My next goal is integration with hatchery and editable tooling for that

I don't have the bandwidth for a correct setuptools version myself and would like to avoid having years of a half-assed solution

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

No branches or pull requests

2 participants