Repository is missing version.py about scikit-hep-testdata HOT 17 CLOSED

It gets generated by setuptools_scm:

When you run pip install ., it makes this file as part of the build process.

from scikit-hep-testdata.

Actually, this is on purpose. Installing it "the right way" (with pip) inserts a version.py, either a tag or a dev version.

from scikit-hep-testdata.

It's not filled when installing it with setup.py. Perhaps that can be considered as a bug?

from scikit-hep-testdata.

This is something I had to get used to, too. python setup.py install is not considered a valid way to install a Python package (anymore). It has to be pip install . or pip install -e . (for development: editing files in the base repo would then affect the installed version).

Maybe we need a statement on the front page saying this because even though it's a general rule now (for all Python projects), I wouldn't have known about it if @henryiii hadn't told me.

from scikit-hep-testdata.

I'm not sure this is about whether setuptools is being called from setup.py vs from pip install. My assumption was that it might work via pip install because the version.py exists on the developer's machine and is then rolled into the published wheel.

from scikit-hep-testdata.

In that case, would it be okay to add use_scm_version=True, setup_requires=['setuptools_scm'] to the setup() call in setup.py.
https://pypi.org/project/setuptools-scm/#setup-py-usage

from scikit-hep-testdata.

Why? The current version works fine, does it not? If something is broken, that should be fixed instead of using old setup.py usages?

from scikit-hep-testdata.

Using setup.py install is my use case that is broken.

from scikit-hep-testdata.

Did you install setuptools_scm[toml]? If you do, it should work. But please don't use setup.py <anything>, that's an implementation detail of setuptools and setup.py is not even required anymore.

from scikit-hep-testdata.

If you want packages to be pre-installed for you, use pip, do not depend on setup_requires, which is an abomination and has been replaced by PEP 517/518 builds.

Note that the current SDist is very much broken, working on that.

from scikit-hep-testdata.

Did you install setuptools_scm[toml]? If you do, it should work. But please don't use setup.py <anything>, that's an implementation detail of setuptools and setup.py is not even required anymore.

I did not have setuptools_scm available during the build and it silently produced installation that would crash on import with

ModuleNotFoundError: No module named 'skhep_testdata.version'

Adding the setuptools_scm, indeed, fixes the issue. Thank you!

from scikit-hep-testdata.

Once the new SDist is out in 0.4.3, you can build from that and it does have version.py in it so setuptools_scm won't be needed when installing from SDist if you don't want it. Soon, setuptools_scm may gain support for git tarballs too, so the version file could even be included in git tarball downloads. So it's only a git checkout that requires setuptools_scm, and only if you don't use python -m pip install . or python -m build, and so don't get a PEP 517 build process.

from scikit-hep-testdata.

Close if you are happy. :)

from scikit-hep-testdata.

If you want packages to be pre-installed for you, use pip, do not depend on setup_requires, which is an abomination and has been replaced by PEP 517/518 builds.

I got bit while trying to package this NixOS/nixpkgs#124557. The usual method of stumbling upon dependencies as they are asked for didn't work ;)

from scikit-hep-testdata.

Close if you are happy. :)

Very much so! Looking forward to using fixed SDist's :)

from scikit-hep-testdata.

I have added

import setuptools_scm  # noqa

before to make it a bit more obvious as to why this fails when it's missing - but if you get it from SDist, you don't actually need setuptools_scm, so it's kind of a 50/50 proposition.

from scikit-hep-testdata.

Probably should see if the version file exists, then try to import setuptools_scm, that would provide the best error messages. But this use case is really quite rare, I think, it's almost always distribution packaging that does this, and there are a limited number of distributions packaging Python packages.

from scikit-hep-testdata.