missing metadata in setup.py

[reneeotten]

When packaging this for MacPorts I realized that it is installed under /opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/platformdirs-0.0.0-py3.9.egg-info/.

Please note the 0.0.0 in the directory name, which is causing issues when dependents check the installed version, which is now reported as being 0.0.0 instead of 2.2.0 (see, for example, this report). Indeed, checking the setup.py/setup.cfg files shows:

% platformdirs-2.2.0 % python setup.py check
running check
warning: check: missing required meta-data: version

can you please add this required meta-data?

[gaborbernat]

Can you please detail exactly how you're trying to package it for macports? This likely is an issue of incorrect packaging on your side than ours.

[gaborbernat]

To me it really seems to be caused by the missing version meta-data

It's not. The version is not statically specified, is provisioned at install time by setuptools-scm. Zero means it cannot provide it, likely due PEP-518 requirements not being met.

[reneeotten]

If you want to use setuptools_scm to provide the packaging information (which is great, but it doesn't work here yet) that's perfectly fine but then you'll likely want to tell setup.py to actually do that, similarly to what's being done in virtualenv.

To me it seems that even if I add py-setuptools_scm as a build dependency it's actually not being used since you don't have the usual

setup(
    ...,
    use_scm_version=True,
    setup_requires=['setuptools_scm'],
    ...,
)

but perhaps I am missing something here?

[Julian]

That information belongs in pyproject.toml (where we already have it) -- any PEP 517 compliant builder will read it from there.

[gaborbernat]

Could be it's not working because you did not define the toml extra for setuptools-scm?

[reneeotten]

ah, that's a good point - adding toml does give now indeed the correct version.

[reneeotten]

We download the source file from PyPI and use the typical python setup.py install mechanism to install the package. You can confirm this yourself by just doing python setup.py --user from the source directory and you'll see that it is installed as "Installed /Users//Library/Python/3.9/lib/python/site-packages/platformdirs-0.0.0-py3.9.egg"

The missing a required metadata field in setup.cfg (see above) is causing this as it is resolved when you add a version field with the correct specifier? To me this doesn't seem like a packaging issue on our side, but just an oversight of not defining the version number correctly.

I'd appreciate if you'd considering fixing this on your side; otherwise we'd have to carry this simple patch forward ourselves.

[gaborbernat]

We download the source file from PyPI and use the typical python setup.py install mechanism to install the package.

You might call this typical but the current Python packaging standards don't support this type of installation and have been unsupported for a few years. setuptools now recommend using pip instead. At the very least you want an installation method that follows the PEP-517+PEP-518 conventions. What you're doing was recommended 10 years ago, but then we got wheels and pip.

You can confirm this yourself by just doing python setup.py --user

No, I don't want to use a not-recommended way of installing the package.

[reneeotten]

the mechanisms with wheels and pip is not going to work well for downstream packagers like MacPorts.

[gaborbernat]

Why wouldn't it work. It's the only method PyPA supports and the only way you'll be packaging any python project independent of the build backend they'll use. E.g. how will you package a poetry project, or a flit one?

[gaborbernat]

👍

[gaborbernat]

The sane and modern way you'd do python packaging in MacPorts is to do:

• run build to generate a wheel - https://github.com/pypa/build (or roll your own PEP-517+518 compatible wheel builder)

• install the generated wheel via one of:

  • pip - https://github.com/pypa/pip
  • installer - https://github.com/pradyunsg/installer

python setup.py install is how things worked 5 years ago, but that was a constant cause of issues (point in case here) so we created PEP-518 and PEP-517 to solve those. Going ahead this new methodology is the (only) recommended and supported way.

Note we're not saying you must use pip, you're free to roll your own wheel installer; however, don't use the old and no longer supported setuptools way to install your python packages. All Python package installations should first generate a wheel and then install that wheel. The wheel format is well formalized in https://www.python.org/dev/peps/pep-0427/. How to generate a wheel is well defined in PEP-517 and PEP-518. python setup.py install hasn't been extended or maintained in years by setuptools maintainers, so most likely you're using an old and outdated way of installing the package, so if you insist on using it don't expect it to work always either way.

[reneeotten]

thanks for the help @gaborbernat - I appreciate your insights! I'll take a closer look at the links in your answer and we can try to come up with a way to package Python packages in a consistent way that "just-works" out-of-the-box for all (or at least covers most) of the packages on PyPI and GitHub.

[gaborbernat]

This solution should cover all, not just most. Anything outside of this spec is currently outside of valid packaging for Python. Note that the build tool currently uses pip to satisfy build dependencies, however it's composable so in case you want the build tools to be satisfied by macports you could write a shim that loads pyproject.toml and translates/installs the dependencies to come from macports. If you start out on this path feel free to reach out to the build project directly (I'm maintainer there too) either via the issues or our chat available under https://discord.gg/pypa

[jmroot]

Your point that you don't support installing with setup.py has been clearly made, but is there any reason not to add version to the setup.cfg?

[gaborbernat]

Because in our project the version is stored within the version control systems metadata section. It's not a static value; it's dynamically calculated by setuptools-scm. If one would add it to setup.cfg we'd have to manually update it; which would defeat the point of setuptools-scm and also make the version property a lie. Static version numbers are always a lie and I prefer to avoid them if I can.

[jmroot]

Isn't that what attr: directives are for?

[gaborbernat]

attrs directive pulls a static version from a python file. It does not calculate on the fly the version number from the SCM.

[jmroot]

OK. I would have thought something like version = attr: setuptools_scm.get_version would do exactly what you wanted, but I'll take your word for it.

[gaborbernat]

You can't call methods in attrs, only pull static version. Even if you could you would be no different than now.