Open mtelka opened 1 year ago
What's your use case? This project only provides C header files, which don't quite work well with Python packaging. I'd be interested in use cases where an sdist would work better than an archive of the Git repo, or a wheel.
(Also, currently, python -m build
can make a sdist, but it doesn't include the headers, so it's useless. But that's solvable.)
I'm packaging py3c for OpenIndiana (together with many other Python projects). We do have semi-automatic tool for packaging such projects. The tool asks PyPI (because PyPI is very comfortable source of information about Python projects) about some information, for example latest released version and URL for source tarball. Once the tool have such information it could package the project. If the initial integration/packaging is done well (often there are some tweaks needed) then we can do project upgrades (re-package, once you release new version) or rebuild for new major Python version automatically.
Currently, with missing sdist at PyPI we cannot automatically find sources. That's not a big problem, since our packaging tool is flexible so we just add something like this in its config file:
COMPONENT_ARCHIVE_URL = \
https://github.com/encukou/py3c/archive/refs/tags/v$(HUMAN_VERSION).tar.gz
This works well, and it is only a minor burden in our tooling, but it could be a problem once the above url no longer works (for example if you switch from github to ..., or move the project from encukou to ..., etc.). In that case we would need to update our config manually, which we would like to avoid, if possible.
So to have the situation a bit simpler for us, we would appreciate source tarball at PyPI (as almost all other Python projects do). But, on the other hand, if it is hard for you to implement, then no problem, we can live without it.
Díky.
Ah. Thanks for the concrete use case, that makes sense!
Could I ask you to send a PR to generate a proper sdist
? It should be enough to add a MANIFEST.in
that lists the *.h
files. I can do it if you run into trouble, but I assume you can test it with OpenIndiana's automation and prevent some back-and-forth.
I just tried this:
$ git clone https://github.com/encukou/py3c.git
$ cd py3c
$ python -m build --no-isolation
...
$ tar tf ./dist/py3c-1.4.tar.gz | grep include
py3c-1.4/include/
py3c-1.4/include/py3c/
py3c-1.4/include/py3c/capsulethunk.h
py3c-1.4/include/py3c/comparison.h
py3c-1.4/include/py3c/compat.h
py3c-1.4/include/py3c/fileshim.h
py3c-1.4/include/py3c/py3shims.h
py3c-1.4/include/py3c/tpflags.h
py3c-1.4/include/py3c.h
$
So it works for me. I tried with Python 3.9.16, setuptools-67.4.0 and build-0.10.0.
BTW, I cannot create PR, because the sdist package construction depends on tools you use (and their version) and I do not know what exactly you use, so I cannot test how it would behave for you. Sorry.
Interesting. With the same versions I get a different result :/
sdist package construction depends on tools you use (and their version) and I do not know what exactly you use
I don't use anything yet. python -m build
sounds good.
The sdist package is missing at PyPI. Please add the source package to PyPI. Thank you.