| commit | a35d4d368a21f4b70afa3195da4d6292a649cb4c | [log] [tgz] |
|---|---|---|
| author | Eli Schwartz <eschwartz@archlinux.org> | Sun May 07 01:21:18 2023 -0400 |
| committer | Eli Schwartz <eschwartz93@gmail.com> | Wed Feb 21 16:47:00 2024 -0500 |
| tree | a450a5ae8255aafe6cba0e267fad6b60fb453264 | |
| parent | 4e5df4b3b7e0db0c4ed174f8b2de53b9004a1c45 [diff] |
ciimage: fix pathological brokenness in homebrew packaging of python Followup to commit 5c479d7a13a518c18ccb4dc3b6bdd7bfc2a9bdb5. In this case, PEP 668 was created to allow a thing that Debian wanted, which is for `pip install foobar` to not break the system python. This despite the fact that the system python is fine, unless you use sudo pip which is discouraged for separate reasons, and it is in fact quite natural to install additional packages to the user site-packages. It isn't even the job of the operating system to decide whether the user site-packages is broken, whether the operating system gets the answer correct or not -- it is the job of the operating system to decide whether the operating system is broken, and that can be solved by e.g. enforcing a shebang policy for distribution-packaged software, which distros like Fedora do, and mandating not only that python shebangs do not contain `/usr/bin/env`, but that they *do* contain -s. Anyway, this entire kerfuffle is mostly just a bit of pointless interactive churn, but it bites pretty hard for our use case, which is a container image, so instead of failing to run because of theoretical conflicts with the base system (we specifically need base system integration...) we fail to run because 5 minutes into pulling homebrew updates at the very beginning, pip refuses point-blank to work. I especially do not know why it is the job of the operating system to throw errors intended for interactive users at people designing system integration containers who cannot "break" the system python anyway as it is thrown away after every use. Fix this by doing what homebrew should have done from the beginning, and opting containers out of this questionable feature entirely.
Latest Meson version supporting previous Python versions:
Meson is available on PyPi, so it can be installed with pip3 install meson. The exact command to type to install with pip can vary between systems, be sure to use the Python 3 version of pip.
If you wish you can install it locally with the standard Python command:
python3 -m pip install meson
For builds using Ninja, Ninja can be downloaded directly from Ninja GitHub release page or via PyPi
python3 -m pip install ninja
More on Installing Meson build can be found at the getting meson page.
Meson can be run as a Python zip app. To generate the executable run the following command:
./packaging/create_zipapp.py --outfile meson.pyz --interpreter '/usr/bin/env python3' <source checkout>
Meson requires that you have a source directory and a build directory and that these two are different. In your source root must exist a file called meson.build. To generate the build system run this command:
meson setup <source directory> <build directory>
Depending on how you obtained Meson the command might also be called meson.py instead of plain meson. In the rest of this document we are going to use the latter form.
You can omit either of the two directories, and Meson will substitute the current directory and autodetect what you mean. This allows you to do things like this:
cd <source root> meson setup builddir
To compile, cd into your build directory and type ninja. To run unit tests, type ninja test.
More on running Meson build system commands can be found at the running meson page or by typing meson --help.
We love code contributions. See the contribution page on the website for details.
The channel to use is #mesonbuild either via Matrix (web interface) or OFTC IRC.
More information about the Meson build system can be found at the project's home page.
Meson is a registered trademark of Jussi Pakkanen.