According to the homepage[1]:
> Small change in Mori.h for compatibility with gcc_10 (thanks to J.
Puydt) [May 15, 2020].
Disabling the strictoverflow seems to be no longer necessary (I'm
relying on the check phase here).
[1] http://hep.itp.tuwien.ac.at/~kreuzer/CY/CYpalp.html
Based on some feedback in #87094 and discussion with @fridh, this re-organizes
the onboarding tutorial in the Nixpkgs manual's python section, so that we start
with the simplest, most ad-hoc examples and work our way up. This progresses
from:
1. How to create an temporary python env at the cmdline, then
2. How to create a specific python env for a single script, then
3. How to create a specific python env for a project in a shell.nix, then
4. How to install a specific python env globally on the system or in a user profile.
Additionally, I've tried to standardize on some of the "best practice" ways of
doing things:
1. Instead of saying that this command style is "supported but strongly not
discouraged", I've just deleted it to avoid confusion.
Bad: nix-shell -p python38Packages.numpy python38Packages.toolz
Good: nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz ])'
2. In the portion where we show how to add stuff to the user's
`XDG_CONFIG_HOME`, use overlays instead of `config.nix`. The former can do
everything the latter can do, but is also much more generic and powerful,
because it can compose with other files, compose with other envs, compose
with overlays that do things like swap whether tensorflow and pytorch are
built openblas/mkl/cuda stacks, and so on. The user is eventually going to
see the overlay, so to avoid confusion let's standardize on it.
Allow the darwin links code to overwrite libs that were already
copied, because C dependencies can occur multiple times.
Solves errors like
ln: failed to create symbolic link '/nix/store/higpc9xavwcjjzdipz7m9ly03bh7iy2z-hercules-ci-agent-source-0.7.0/lib/links/libboost_context.dylib': File exists
