Every package should have a maintainer and we should not throw it away if we arleady have one.
Also in reality the maintainer of python3 is also the one of python3-minimal
GCC does not come with a `libgcc_eh.a` for the target platform if
it was built without `--enable-shared`. That flag was removed with
c6dd11ca39, meaning we should no longer
attempt to link against that lib.
We have a common pattern here in nixpkgs for Python applications: when a
Python package ships with either a requirements.txt or setup.py file, we
generally end up having to modify its version restriction, otherwise we have
build failures since we package only one specific version of each package
normally.
However, this end up being done in a completely ad-hoc way: some people
use substituteInPlace, some others use sed, others uses patches, etc.
In many cases, the code ends up being buggy, so it may work in one
version and breaks on the next one. We can instead implement one
standard way of doing this, and trying to be a correct as possible.
So this is what this commit does: it implements a new build hook, that
when called will automatically patch the wheel file. This is one of the
most generic ways to patch Python dependencies, and should work in
multiple cases.
Noticed option globbing when tried to enable parallelism by default
locally for most packages by default. python3Packages.yt-dlp failed as:
python3.9-yt-dlp> /nix/store/5mywvxdjkk1q6srwwwgdkzc37ibla801-python3.9-setuptools-61.2.0/lib/python3.9/site-packages/setuptools/dist.py:516: UserWarning: Normalizing '2022.04.08' to '2022.4.8'
python3.9-yt-dlp> warnings.warn(tmpl.format(**locals()))
python3.9-yt-dlp> invalid command name 'build_lazy_extractors--parallel'
The change adds leading whitespace everywhere where options might
already be present.
Overriding the interpreters did not work correctly. When overriding
packages would end up twice in the build time closure: one corresponding
to the overridden interpreter and one corresponding to the original
interpreter. The reason is that the override was not applied to the
interpreters in the spliced package sets.
This simplifies usages and makes the default value consistent.
In a few cases, the default value was interpreted to be `false`,
but this is useless, because virtually nobody will explicitly
set `allowAliases = true;`.
It seems the additional linker flags were added in 9d3b0a2 (May 2008) as
a workaround for readline support. They were kept since then, but it
also means that `python3-config` outputs these flags
```console
$ python3-config --libs
-lpthread -ldl -lcrypt -lncurses -lutil -lm -lm
```
while other GNU/Linux distros do not. For example, Debian 11:
```console
$ sudo apt install python3-dev
$ python3-config --libs
-lcrypt -lpthread -ldl -lutil -lm -lm
```
This change removes the `-lncurses` flag and aligns Nix/NixOS with other
distros.
Conflict in pkgs/development/libraries/libvirt/default.nix
required manual adjustments. The fetched patch is already in src.
I checked that libvirt builds.
Avoids situations where a branch and tag share the same
label. Github will silently return a non-valid artifact and
will fail the build.
Since all github releases correspond to an annotated tag, it's
safe to assume that if we found a release for a tag, that the
tag will exist.
they ship their own openssl
as of this commit, that is actually openssl 1.1.1m, the same version we have in openssl_1_1
maybe the package should still be marked as vulnerable, because they ship their own openssl
The original motivation behind removing that was to appease a consumer
of python-config's output. That issue was probably resolved by now, so
let's bring the build in sync with what python is doing by default.
This reverts b7819e38 ('python3.x: Patch extra stack size on darwin')
Setting an old target conflicts with the -stack_size,1000000 linker
flag. This fixes build of python310.
This reverts ce59dec5 ('python34: as a workaround, explicitly set MACOSX_DEPLOYMENT_TARGET')
This reverts commit d003f75d78.
Causes an unnecessary amount of breakages due to a DeprecationWarning
regarding the loop argument in asyncio, that is going to be deprecrated
in Python 3.10.
> 'The loop argument is deprecated since Python 3.8, and scheduled for removal in Python 3.10.'
The ecosystem needs more time to catch up here. Broken packages are for
example aiohttp, argh and by extension alot of other packages.
