Install zig directly in bin/ and lib/zig/ under sys.prefix

[orent]

This enables running it directly without python -m ziglang

Also builds a universal py2/py3 wheel

[orent]

I see from another pull request that not having 'zig' is intentional. It can be named something else instead e.g. 'zig-pypi' or 'ziglang'

[whitequark]

It can be named something else instead e.g. 'zig-pypi' or 'ziglang'

If you're already changing the command you're running I don't see why zig-pypi is any worse than python3 -m ziglang; and python3 -m ziglang is strictly better because you might have a lot of Python installations (especially when virtualenv is involved).

[orent]

This is mostly about adhering to the same path conventions as other system level and userspace distributions. Under the base path (/usr, /usr/local, ~/.local etc) files are stored in bin/, lib/ etc.

While distributing non-Python tools this way is not so common in PyPI, it is the norm with Conda, for example, another packaging system for Python popular among data scientists. https://anaconda.org/conda-forge/zig

This also avoids another execution of the Python interpreter, which has a non-negligible startup time.

Personally, I don't see why the default zig executable name should be a problem in the first place (PR #4). This is exactly what happens with the python interpreter in venv. and with other executables (including zig) on other virtual environment and systems and userspace distributions. Activating an environment is explicitly asking for this behavior. If you don't want it just use the full path without activating or adding to PATH

[whitequark]

While distributing non-Python tools this way is not so common in PyPI, it is the norm with Conda, for example, another packaging system for Python popular among data scientists. https://anaconda.org/conda-forge/zig

Conda is a general-purpose package manager while PyPI isn't.

Personally, I don't see why the default zig executable name should be a problem in the first place

The way I see it is that zig-pypi distributes a toolchain that can be used by other Python libraries and binaries. I never intended it to be another user-facing method of installing Zig, and adding things to PATH shadowing the system-wide installation of Zig (which is what would happen when you install system- or user-wide) because a package is being installed as a dependency of something else is clearly harmful.

[whitequark]

adding things to PATH shadowing the system-wide installation of Zig (which is what would happen when you install system- or user-wide)

When I wrote this I did not understand the full extent of the issue here. I've just ran pip install ziglang-....whl built from this PR and looked at what it actually does. It's not just shadowing the system-wide Zig installation. If you run, outside of a venv, pip install ziglang and this wheel gets installed, it writes into /usr/local/bin/zig (as well as /usr/local/lib, etc).

Having re-read your comments I now understand that this is the goal here. However, I think this behavior is both surprising (that's not how Python packages normally behave) and extraordinarily inappropriate. The user may have had their own version of Zig installed in /usr/local, which is now gone! Or, they may start using the PyPI version without realizing where it got installed, and then have it get overwritten when they build their own Zig binaries.

When I designed zig-pypi, I made it with the explicit intent that this installation of Zig will live in site-packages. That was the whole point: to have an installation of Zig that will never, in any way, intersect with anything that's installed system-wide, so that it can be treated by downstream software as an ordinary Python dependency (that just happens to ship as native code).

None of this matters if you use a virtual environment, but unless there is some way to make this package behave the way it does in this PR if and only if it's being installed in a virtual environment, this is a hard "no" from me, sorry.