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

LewisGaul commented 2021年07月12日 23:54:17 +02:00 (Migrated from github.com)

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!

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 2021年07月13日 05:36:13 +02:00

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.

> 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 2021年07月13日 09:28:53 +02:00 (Migrated from github.com)

Makes sense, thanks!

Makes sense, thanks!