search

ziglang / zig-pypi

The Zig programming language, packaged for PyPI
https://pypi.org/project/ziglang/
MIT License
148 stars 16 forks source link

Question: why not using setuptools/setup.py? #2

Closed LewisGaul closed 3 years ago

LewisGaul commented 3 years ago

Feel free to ignore if unhelpful, but I was wondering why a custom make_wheels.py script is being used rather than a standard setup.py script (or perhaps setup.cfg or pyproject.toml) with setuptools? I imagine there's a good reason that I'm not seeing :)

Perhaps worth pointing out that https://github.com/pypa/wheel#wheel states:

It should be noted that wheel is not intended to be used as a library, and as such there is no stable, public API.

The reason I was wondering is I was thinking it might be helpful to give the ziglang package a zig entrypoint, i.e. when installing into a venv with pip install ziglang you would get a venv/bin/zig executable, which would be on PATH when the venv was active. Definitely not necessary for the intended use-case, and not obviously desirable in general, but was just a thought that this could be used as a slight abuse of PyPI/pip just for installing zig!

whitequark commented 3 years ago

Feel free to ignore if unhelpful, but I was wondering why a custom make_wheels.py script is being used rather than a standard setup.py script (or perhaps setup.cfg or pyproject.toml) with setuptools?

That's what I started with, but it turned out to require more effort to develop (you have to unpack the upstream distribution to the filesystem and appropriately clean up afterwards, for one).

Also, you don't get reproducible wheels that way.

It should be noted that wheel is not intended to be used as a library, and as such there is no stable, public API.

(I also patch internal methods of WheelFile, so it's not like we can rely on API stability guarantees.)

The reason I was wondering is I was thinking it might be helpful to give the ziglang package a zig entrypoint

Also something I was thinking about. Consider, however, that it would be unfortunate if the ziglang package, when installed by a dependency of some Python project in your $HOME/.local/bin (perhaps you ran pip install --local), would override your system-wide zig binary.

Of course, the entry point installed by the ziglang PyPI package could be namespaced. But python -m is already a form of namespacing--one that is perfectly in sync with the way you already run Python.

LewisGaul commented 3 years ago

Makes sense, thanks!