The function buildGoModule builds Go programs managed with Go modules. It builds
a Go module through a two phase build:
- An intermediate fetcher derivation. This derivation will be used to
fetch all of the dependencies of the Go module.
- A final derivation will use the output of the intermediate derivation
to build the binaries and produce the final output.
Since Intel's default openmp implementation is available in the same src
tarball, we can just include it in the package. This means that `mkl` now "just
works" without any environment variables, fragile setup-hooks, or forced
propagation.
Since the openmp implementation is only needed at runtime (and for test cases),
users can substitute a different one if they prefer by exporting it with
`LD_PRELOAD`, which is how Intel recommends handling this. If they do not do so,
`libiomp.so` lives next to `libmkl_rt.so` and thus will be in the RPATH as a
sane default.
Since this still comes from the same src tarball, we can ship it without losing
the fixed-output derivation; likewise, since Hydra is not building or caching
these, shipping these proprietary packages costs no bandwidth for the nix
community.
Python 3.4 will receive it's final patch release in March 2019 and there won't
be any releases anymore after that, so also not during NixOS 2019.03.
Python 3.4 is not used anymore in Nixpkgs. In any case, migrating code from
3.4 to 3.4+ is trivial.
This commit renames the pythondaemon module to match its module name, github
name, and pypi name, which makes it easier to find and reference. In order to
avoid breaking any external users, I've left an alias with a deprecated warning.
The `name` arg of `vim_configurable.customize` does not only determine
the package name, but also the name of the command/ executable to be
called.
In my opinion this is not documented properly and finding that out took
me several hours.
This touches up a handful of places in the python documentation to try to make
the current best-practices more obvious. In particular, I often find the
function signatures (what to pass, what not to pass) confusing and have added
them to the docs.
Also updated the metas to be more consistent with the most frequently used
modern style.
A new python script has been added to replace the aged viml-based
updater. The new updater has the following advantages:
- use rss feeds to check for updates quicker
- parallel downloads & better caching
- uses proper override mechanism instead of text substitution
- update generated files in-place instead of having to insert updated plugins manually
Automatically reading `dependencies` from the plugins directory has been
not re-implemented.
This has been mostly been used by Mark Weber's plugins, which seem to
no longer receive regular updates.
This could be implemented in future as required.
Use example package `zerobin` instead of `bepasty-server` which
is no longer part of python-packages.
This fixes the examples for current nixpkgs versions.
1. Use the same approach like in the overlay example:
Override `python` instead of `pythonPackages` so that
`python.pkgs` refers to the new package set like `pythonPackages`.
This also fixes a bug in the original example where
`pkgs.fetchgit` was not in scope.
Add an extra example to illustrate how to override just a
package set.
2. Fix mix-up between `super` and `self` in the explanation text.
Also, simplify the explanation.
This fixes a regression introduced in 4b06383.
[dezgeg squashed in to fit the changes introduced in "db: Use more
conventional outputs, also split bin"]
Relevant section: 9.5.2.3. How to install a compiler with libraries, hoogle and documentation indexes
Since version 5 `hoogle server`s --local flag solves the problem with links from
`http:` to `file:` URIs:
hoogle server --local -p 8080
Setting haskell.packageOverrides like so:
haskell = super.haskell // {
packageOverrides = self: super: {
my-package = ...;
my-other-package = ...;
};
};
causes all compiler-specific package sets to be overridden with those
overrides.
Nobody has stepped up to keep maintaining this and it's several
years old, and the last strict Java 7 dependency, as it won't work
with newer versions without an update.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
- Add example for setting up nix-shell, improve rust docs
- Rust docs: add gcc rust dependencies and fix carnix commands
- Fix a typo with the carnix command.
* trying to build emscriptenPackages not all fail
* reading the console.log it turns out python executable is not in place and that is why emconfigure didnt work
* backup commit
* much more targets are compiling now
* added common revisioning
* revision bump to 1.37.36 (not tested)
* fixed xmllint
* forcing unit testing, will implement the tests after i get home
* json_c test working
* added tests
* tiny fixes
* added documentation
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
This involved:
* Installing miniperl as $dev/bin/perl
* Setting miniperl to take INC from
lib/perl5/{site_perl/,}cross_perl/${version} as well as
lib/perl5/{site_perl/,}/${version}/${runtimeArch}, in that
order. miniperl taking from runtimeArch is not really correct, but
it works in some pure-perl cases (e.g. Config.pm) and can be
overridden with the cross_perl variant.
* Installing perl-cross's stubs into
$dev/lib/perl5/cross_perl/${version}
* Patching MakeMaker.pm to gracefully degrade (very slightly) if B.pm
can't be loaded, which it can't in cross-compilation.
* Passing the right build-time and runtime perls to Makefile.PL
The biggest benefit is that we no longer have to update the registry
package. This means that just about any cargo package can be built by
nix. No longer does `cargo update` need to be feared because it will
update to packages newer then what is available in nixpkgs.
Instead of fetching the cargo registry this bundles all the source code
into a "vendor/" folder.
This also uses the new --frozen and --locked flags which is nice.
Currently cargo-vendor only provides binaries for Linux and
macOS 64-bit. This can be solved by building it for the other
architectures and uploading it somewhere (like the NixOS cache).
This also has the downside that it requires a change to everyone's deps
hash. And if the old one is used because it was cached it will fail to
build as it will attempt to use the old version. For this reason the
attribute has been renamed to `cargoSha256`.
Authors:
* Kevin Cox <kevincox@kevincox.ca>
* Jörg Thalheim <Mic92@users.noreply.github.com>
* zimbatm <zimbatm@zimbatm.com>
1. Call `nix-build` with `--no-out-link` to avoid cluttering the source dir.
2. Re-add `patchShebangs`, since `buildCommand` doesn't imply a patch phase. (It was my fault to remove this in the first place, sorry!)
This allows one to always override the call to `buildPythonPackage`.
In the following example we create an environment where we have the `blaze` package using an older version of `pandas`. We override first the Python interpreter and pass `packageOverrides` which contains the overrides for packages in
the package set.
```
with import <nixpkgs> {};
(let
python = let
packageOverrides = self: super: {
pandas = super.pandas.overridePythonPackage(old: rec {
version = "0.19.1";
name = "pandas-${version}";
src = super.fetchPypi {
pname = "pandas";
inherit version;
sha256 = "08blshqj9zj1wyjhhw3kl2vas75vhhicvv72flvf1z3jvapgw295";
};
});
};
in pkgs.python3.override {inherit packageOverrides;};
in python.withPackages(ps: [ps.blaze])).env
```
