Followup to commit 5c479d7a13.
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.
The following workflows have been updated so that they are
triggered when the any of the test harnesses are updated:
macos,
os-comp,
msys2
Previously only changes to `run_unittests.py` caused these
workflows to be executed.
Commit 191449f608 has numerous issues, and
being completely invalid yml syntax was just the tip of the iceberg.
In this case, it fails the github schema, which requires that env be
adjunct to a job or step definition, rather than its own thing. It did
not even make sense in context, since the purpose of the variable is to
modify brew.
Fixes: #12644Fixes: #12681
We're getting errors that we don't care about on the CI like:
```
==> Pouring node@18--18.19.0.monterey.bottle.tar.gz
The formula built, but is not symlinked into /usr/local
Error: The `brew link` step did not complete successfully
Could not symlink lib/node_modules/npm/docs/content/commands/npm-sbom.md
Target /usr/local/lib/node_modules/npm/docs/content/commands/npm-sbom.md
already exists. You may want to remove it:
rm '/usr/local/lib/node_modules/npm/docs/content/commands/npm-sbom.md'
```
We don't care about node, the only reason it's getting updated is
because it's already installed on the image and brew is auto-updating
it. So let's disable auto-update.
The former has rust dependencies, which lead to max capping on Cygwin
since there is no rust compiler there. But it turns out there are other
disadvantages of jsonschema:
- it involves installing 5 wheels, instead of just 1
- it is much slower
To give some perspective to the latter issue, this is what it looks like
when I test with jsonschema:
```
===== 1 passed, 509 deselected in 3.07s =====
Total time: 3.341 seconds
```
And here's what it looks like when I test with fastjsonschema:
```
===== 1 passed, 509 deselected, 1 warning in 0.28s =====
Total time: 0.550 seconds
```
I cannot think of a good reason to use the former. Although in order to
work on old CI images, we'll support it as a fallback mechanism
This is a no-op change from v2 to v3, but github complains that nodejs
is outdated if you don't. It's not obvious why this required a major
version bump...
However, half of our uses are on v1, which has a decent fix: failure to
upload artifacts constitutes a step failure.
Not much changes, really, other than it now sets PKG_CONFIG_PATH to
point to the python it just installed. This should generally not be a
problem (Meson's python module sets that anyway based on the
executable's introspection data).
Downgrade to LLVM-14 from LLVM-15 which is somewhat broken when using
static linking at present:
https://github.com/Homebrew/discussions/discussions/3666#discussioncomment-3681821
We can't use LLVM's lld instead of ld on macOS because we don't detect
it as an Apple linker and pass --as-needed etc to it. Even when that
is fixed and we set -lto_library etc correctly, the linker just hangs.
LLVM@14 is keg-only, so we need to add CPPFLAGS / LDFLAGS to the keg
subdir inside /usr/local
The LLVM@15 test is shared-only now and moved to the qt4 macOS job.
The $CI environment variable may be generally set by Github or Gitlab
actions, and is not a reliable indicator of whether we are running "CI".
It could also, for an absolutely random example that didn't *just
happen*, be Alpine Linux's attempt to enable the Meson testsuite in
their packaging, which... uses Gitlab CI.
In this case, we do want to perform normal skipping on not-found
requirements. Instead of checking for $CI, check for $MESON_CI_JOBNAME
as we already use that in all of our own CI jobs for various reasons.
This makes it easier for linux distros to package Meson without
accumulating hacks like "run the testsuite using `env -u CI`".
Previously the meson test case would only test boost-python on linux.
With the #7909 it is now possible to use boost-python on macOS/homebrew.
This enables the boost-python test on both linux and macOS.
It also uses python.extension_module() instead of shared_library to make the
python extension module.
Set MESON_CI_JOBNAME for all CI jobs which run project tests.
(Note that ${{ github.job }} is the literal job.id used in the yaml, not
any name given to the job with job.id.name, and so is the same for all
matrix entries, and thus not suitable for our purposes there).
Dylan Baker
Jonathan Schleifer
Eli Schwartz
Andrew McNulty
Eli Schwartz
Chris Mayo
Nirbheek Chauhan
Charles Brunet
L. E. Segovia
Carlo Cabrera
neilnaveen
Jan Tojnar
Daniel Mensinger
Kevin Meagher
Xavier Claessens
Jon Turney