Editable install report outdated version after tagging occured #518
Comments
|
currently setuptools_scm is not aware of package metadata and editable installs in a meaningful way sane support would need a extra step in editable installs that does update the metadata in meaningful ways , potentially via git/hg hooks it would be a major feature that i cant start on in the next 6-18 months |
|
I wonder if we can do some kind of alternative where we would report some kind of custom version number that indicates that this is an editable install that may not have exact version, at least to avoid misleading users with really outdated tags. This is quite annoying for developers as I still see my tools reporting misleading versions that are many months old, only because I never needed to run install again. |
|
Unfortunately that is a breaking mechanism Post commit /checkout hooks as opt in may help |
The [setuptools documentation](https://setuptools.readthedocs.io/en/latest/pkg_resources.html) discourages the use of pkg_resources directly as there's performance overhead at runtime. Similarly, [usage in Sphinx](https://github.com/pypa/setuptools_scm#usage-from-sphinx) is discouraged. Both references suggest `importlib.metadata` instead. It also seems strange to me to require setuptools-scm to be installed, as this is something that pip pulls in to the build environment when it is needed. So I have removed requirements for it, and references to it in the code, opting for `importlib` as recommended. I've also removed the `setup_requires` kwarg from `setup.py`, in favour of the list of build requirements in `pyproject.toml`. Identifiers for editable installs were [rejected from PEP660](https://www.python.org/dev/peps/pep-0660/#editable-local-version-identifier), at least as far as annotating the `version` specifier goes. This breaks things with pip. For versioning from within editable installs, some others seem to have implemented something [vaguely similar to katversion](pypa/setuptools-scm#273 (comment)). The maintainer of setuptools_scm says that [there's no good solution to the editable installs problem right now](pypa/setuptools-scm#518). We could perhaps consider a (clunky) workaround like [this](https://stackoverflow.com/questions/43348746/how-to-detect-if-module-is-installed-in-editable-mode#57854737). My personal feeling is that an editable install is an exceptional case that we shouldn't optimise for - I think the onus is on the developer to remember that they are working in one, and not let the ambiguity get the better of them. But I am willing to consider other points of view on this.
Once an editable install is performed the version reported by it remains the same even if the code was updated and a new tag was added.
At this moment the only workaround is to run
pip install -e .again, as this will uninstall and reinstall the package and correct the the version.As this is quite inconvenient and very easy to happen for developers we should better find a way to recalculate the version dynamically, without requiring a reinstallation, or at least to find a way to detect this needs to happen.
It seems that the editable install is mainly an
pkgname.egg-linkfile that points to the location of the module, a place where we also have a cachedpackagename.egg-infofolder which contains the version.I am not sure if we have any hooks or tricks that could be used to refresh the outdated version.
The text was updated successfully, but these errors were encountered: