Using the pytables internal c-blosc lead to a compilation error on
darwin, as the installer uses cpuinfo.get_cpu_info(), which
(unexpectedly for pytables) returns None in the current darwin-python.
If `git-flow` was installed without explicitly installing `getopt` and `git`
too, it couldn't find those executables. Now it can find those and it can be
used as `git-flow` executable. Note, however, that in order to use `git-flow` as
git subcommand (`git flow`), one needs to install `git` too.
In the extremely unlikely case that our store hash path ends in several
digits (as is the case right now), the Darwin ld will try to interpret
those digits as a version number and barf. To avoid that, we pass in the
SDK version explicitly to stop it from trying to figure it out from iffy
context.
The Python package has two packages for requests, `requests`
corresponding to version 1.2.3, and `requests2` corresponding to version
2.13.0. Version 1.2.3 is almost 4 years old, and by now all software
should have transitioned.
This commit aliases `requests` to `requests2`. Packages that stop to
function should be upgraded. In the rare case that that is not possible,
version 1.2.3 is still available as `requests_1` but I plan to drop
that before the release of 17.09.
The Sierra linker added a limit on the number of paths that any one
dynamic library (`*.dylib`) can reference. This causes problems when
a Haskell library has many immediate dependencies (#22810).
We follow a similar fix as GHC/Cabal/Stack: for each derivation,
create a new directory with symlinks to all the dylibs of its immediate
dependencies, and patch its package DB to reference that directory
using the new `dynamic-library-dirs` field.
Note that this change is a no-op for older versions of GHC, i.e., they will
continue to fail on some packages as before.
Also note that this change causes the bootstrapped versions of GHC to be
recompiled, since they depend on `hscolour` which is built by
`generic-builder.nix`.
Tested by building the `stack` binary as described in #22810.
IPFS uses the environment variable IPFS_PATH to determine where to look for it's data, which wasn't set previously therefore ignoring the dataDir attribute
