Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 2 commits into from

Conversation

orent
Copy link

@orent orent commented Sep 6, 2022

This enables running it directly without python -m ziglang

Also builds a universal py2/py3 wheel

so it can be executed directly. Docs moved to share/doc/zig/

'python -m ziglang' still works for compatibility but not really
necessary now.
@orent
Copy link
Author

orent commented Sep 6, 2022

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
Copy link
Collaborator

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
Copy link
Author

orent commented Sep 7, 2022

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
Copy link
Collaborator

whitequark commented Sep 7, 2022

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
Copy link
Collaborator

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.

@whitequark whitequark closed this May 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants