Specifying package version in `setup.py`

I’m trying to upload my first package to PyPI. I’m specifying version="0.1.0" in setup.py, and version = 0.1.0 in setup.cfg. Still, when I run python setup.py --version I get 0.0.post1.dev2+g1e7307d.d20220319, which is not upload-able to PyPi.

Does anyone see anything glaring I’m doing wrong?

Oh jeez, it seems like specifying a local git tag v0.1.0 worked… is git required for Python package versioning? Why does python setup.py sdist ignore whatever version is in setup.cfg and instead use the local git tag?

Oh jeez, it seems like specifying a local git tag v0.1.0 worked… is
git required for Python package versioning?

No.

I wire a version directly into my setup.py, and that version does not
come from git.

Maybe this is some convenient behaviour if there’s no valid version=
for setup().

Why does python setup.py sdist ignore whatever version is in
setup.cfg and instead use the local git tag?

I think something else is going on. If you haven’t sorted your version
issue from the previous post, that may be why it has no effect.

Please show us your setup.py file. Here’re a working example from my
end. You can see that the version is just a string. It has to conform to
the version spec of course.

#!/usr/bin/env python
from setuptools import setup
setup(
  name = 'cs.x',
  author = 'Cameron Simpson',
  author_email = 'cs@cskk.id.au',
  version = '20211208',
  url = 'https://bitbucket.org/cameron_simpson/css/commits/all',
  description =
    'X(), for low level debugging.',
  long_description =
    'X(), for low level debugging.\n ...... long description snipped .....',
  install_requires = ['cs.ansi_colour'],
  classifiers = ['Programming Language :: Python', 'Programming Language :: Python :: 2', 'Programming Language :: Python :: 3', 'Development Status :: 4 - Beta', 'Intended Audience :: Developers', 'Operating System :: OS Independent', 'Topic :: Software Development :: Libraries :: Python Modules', 'License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)'],
  keywords = ['python2', 'python3'],
  license = 'GNU General Public License v3 or later (GPLv3+)',
  long_description_content_type = 'text/markdown',
  package_dir = {'': 'lib/python'},
  py_modules = ['cs.x'],
)

Cheers,
Cameron Simpson cs@cskk.id.au

It’s because you’re using the setuptools-scm plugin. Either learn
how it works, or take it out of your build-system.requires:

As @fungi mentioned, the issue you ran in to was due to unknowingly using setuptools_scm. Some additional comments:

It is good that you are using a setup.cfg, but specifying the same metadata both places not only is unnecessary (and negates the benefit of using a static, declarative setup.cfg in the first place) but I’m not even sure which Setuptools uses (or whether it results in an error). However, looking at your actual setup.py it looks like its just a stub exactly as recommended, so it seems this part just might be a misunderstanding.

FYI, nowadays, you should never invoke setup.py directly; doing so is deprecated and will eventually stop working (and already has for a number of long-deprecated commands). Instead, use the modern replacements specified there.

I’m not sure about the former since I’ve never seen setup.py --version used in actual practice, but the latter should be replaced by build, the standard modern build frontend that works with any build backend (not just Setuptools). Just install it (e.g. pip install build) and then build both your sdist and your wheel at once by running python -m build.

FYI, it looks like that example is completely static and declarative, and can be ported directly to a modern setup.cfg automatically using e.g. setup-py-upgrade, leaving only a stub setup.py to retain backwards compatibility with legacy tooling, e.g.

#!/usr/bin/env python
from setuptools import setup

if __name__ == "__main__":
    setup()

This will also make it easy to automatically upgrade it further using ini2toml to standardized PEP 621 source metadata and build packend configuration in your pyproject.toml, once Setuptools’ PEP 621 support stabilizes (see pypa/setuptools#1688), so all your packaging configuration is in one standard, interoperable and easy to read and write place.

FYI, it looks like that example is completely static and declarative, and can be ported directly to a modern setup.cfg automatically using e.g. setup-py-upgrade, leaving only a stub setup.py to retain backwards compatibility with legacy tooling, e.g.

#!/usr/bin/env python
from setuptools import setup

if __name__ == "__main__":
   setup()

So setuptools.setup will consult the static config file? That is
welcome.

This will also make it easy to automatically upgrade it further using
ini2toml to standardized PEP 621 source metadata and build packend
configuration in your pyproject.toml, once Setuptools’ PEP 621
support stabilizes (see
pypa/setuptools#1688),
so all your packaging configuration is in one standard, interoperable
and easy to read and write place.

Yes, I plan to do this when I find some spare time. I’ve got a monorepo
and my build stuff is all generated by a script for whichever package
I’m uploading.

I do have one package which has a small C extension for its performance
bottleneck.

Cheers,
Cameron Simpson cs@cskk.id.au

Yep, all the way back since 30.3.0 in 2016, though things have improved steadily since then; I recommend specifying a minimum of 42.0.0 in your pyproject.toml’s build-system section (since it will be installed automatically for you if needed in the isolated build env, for any users installing from source and not a wheel, and has still been out for a few years) . It can actually replace a lot of substantially more complex cases than yours, as for many keys it can actually read them from files, attributes of your package, etc that you specify.Here’s the docs which I should have linked before, sorry.

Great, that should make things easy then.

Hmm, if its Cython or can be ported to it, it should be handled for you automatically, but you still might need a bit of non-trivial setup.py code. However, other C build systems are adding PEP 517 support and are way more functional than Setuptools in this respect, such as Scikit-Build (wrapping CMake) and Meson, though are probably overkill for your use case.