setuptools_scm icon indicating copy to clipboard operation
setuptools_scm copied to clipboard

After switching to setuptools_scm my package installed as version 0.0.0

Open polm opened this issue 5 years ago • 9 comments
trafficstars

I tried switching to setuptools_scm for my package fugashi for v0.1.7 but when installing from pip the version is shown as 0.0.0. I saw the notes about conflicting settings in setup.cfg and such but I don't have any of that. In the source PKGINFO the version seems to be correctly set to 0.1.7. What did I do wrong?

Here's a link to setup.py at the 0.1.7 release.

I saw several other issues about this in this repository but none of them seemed to be the same as this.

polm avatar Dec 27 '19 06:12 polm

i think its related to a pip interaction issue i had trouble replicating before, i'm going to investigate if your particular issue fits that

if that's the case then #345 should eventually fix it after i managed to reproduce

RonnyPfannschmidt avatar Jan 08 '20 20:01 RonnyPfannschmidt

I hit the same problem with a pyproject.toml like:

[build-system]
requires = ["setuptools>=42", "wheel", "setuptools_scm[toml]>=3.4"]

[tool.setuptools_scm]
write_to = "ward/_ward_version.py"

Running setuptools results in my package having version 0.0.0, even if I change the version_scheme.

It seemed to work fine when I used setuptools 41, and setup.py.

darrenburns avatar Jan 17 '20 17:01 darrenburns

@darrenburns that release is not out - it should be tommorow

RonnyPfannschmidt avatar Jan 17 '20 18:01 RonnyPfannschmidt

It doesn't work for me either. I have set it up using pyproject.toml exactly like the docs say:

[build-system]
requires = ["setuptools>=42", "wheel", "setuptools_scm[toml]>=3.4"]

[tool.setuptools_scm]

Invoking python setup.py --version returns 0.0.0 and any build will have that version. I had to add the stuff to setup.py to get it to work. I have the latest setuptools installed in my virtualenv. I'm not sure what I'm doing wrong.

georgek avatar Feb 11 '20 10:02 georgek

@georgek to use setup.py as you write, you either need the latest setuptools and the latest setuptools_scm pre-installed or as setup_requires in setup.py/cfg,

setup.py invocations will NOT install build requirements from pyproject.toml

if you have a modern pip installed, i believe a pip wheel . should produce the desired results

RonnyPfannschmidt avatar Feb 12 '20 07:02 RonnyPfannschmidt

@RonnyPfannschmidt Thanks for the clarification. It makes sense. But I think there is a gap in the documentation currently because it suggests the the pyproject.toml method is a direct replacement for using the "legacy" setup.py settings.

The gap seems to be some way to actually install your build requirements from a pyproject.toml file. Is there any recommended way to do that? pip wheel isn't a great solution and I don't want to maintain a dev-requirements.txt which duplicates those build requirements.

georgek avatar Feb 12 '20 13:02 georgek

there is currently indeed no good way, currently they have to be replicated

unfortunately the peps for package metadata do not yet have the accompanying pep for editable installs, there is some work on those pep's from volunteers but they are stretched and its a topic where passovr/coop can be hard to facilitate

RonnyPfannschmidt avatar Feb 12 '20 20:02 RonnyPfannschmidt

For anyone finding this, one way to ensure the build deps are present is to use tox to do your builds. Add to your tox.ini:

[testenv:build-dist]
skipsdist = True
skip_install = True
deps =
     -U
     setuptools>=42
     wheel
     setuptools_scm[toml]>=3.4
commands = python setup.py sdist

And then: tox -e build-dist

georgek avatar Mar 04 '20 13:03 georgek

FWIW I stumbled across this and found that the "easiest" way to make sure this works as intended (instead of silently falling back to 0.0.0) is to import setuptools_scm at the top of setup.py — it'll fail to import if the package is not installed.

Flameeyes avatar Mar 25 '20 14:03 Flameeyes