| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |\| | |
|
| | |/
| |
| |
| | |
The default for `python3` is currently `python36`.
|
| |\| |
|
| | |\
| | |
| | | |
buildDunePackage: add support function and use it in a few packages
|
| | | | |
|
| | |/
| |
| |
| |
| |
| | |
It's incorrect (preferLocalBuild does not prevent uploading to binary
caches) and is not a stdenv attribute (it's already documented in the
Nix manual).
|
| | |\
| | |
| | | |
[RFC] Use `meta.tests` to link from packages to the tests that test them
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Rationale
---------
Currently, tests are hard to discover. For instance, someone updating
`dovecot` might not notice that the interaction of `dovecot` with
`opensmtpd` is handled in the `opensmtpd.nix` test.
And even for someone updating `opensmtpd`, it requires manual work to go
check in `nixos/tests` whether there is actually a test, especially
given not so many packages in `nixpkgs` have tests and this is thus most
of the time useless.
Finally, for the reviewer, it is much easier to check that the “Tested
via one or more NixOS test(s)” has been checked if the file modified
already includes the list of relevant tests.
Implementation
--------------
Currently, this commit only adds the metadata in the package. Each
element of the `meta.tests` attribute is a derivation that, when it
builds successfully, means the test has passed (ie. following the same
convention as NixOS tests).
Future Work
-----------
In the future, the tools could be made aware of this `meta.tests`
attribute, and for instance a `--with-tests` could be added to
`nix-build` so that it also builds all the tests. Or a `--without-tests`
to build without all the tests. @Profpatsch described in his NixCon talk
such systems.
Another thing that would help in the future would be the possibility to
reasonably easily have cross-derivation nix tests without the whole
NixOS VM stack. @7c6f434c already proposed such a system.
This RFC currently handles none of these concerns. Only the addition of
`meta.tests` as metadata to be used by maintainers to remember to run
relevant tests.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\| |
| | |
| | |
| | | |
Conflict: rename of pythondaemon -> python-daemon.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \ |
|
| | |\| | |
|
| | | |/ |
|
| |\| | |
|
| | |\| |
|
| | | | |
|
| | | | |
|
| | | |\
| | | |
| | | | |
minor fixes in Nixpkgs stdenv docs
|
| | | | | |
|
| | | | | |
|
| | | |\ \
| | | |/
| | |/| |
clarifying `name` arg determines vim command name
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |\ \
| | | |/
| | |/| |
breakpointHook: add for debugging failing builds
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | | |
With Python 3.7 now at 3.7.1, and Python 3.6 at it's final maintenance
mode release, it is time to move on to 3.7 as the default interpreter.
|
| |\| | |
|
| | |\ \
| | | |
| | | | |
pkgs.extend for adding overlays
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
section
|
| | | | | |
|
| | | |/
| |/|
| | |
| | |
| | | |
Allows for adding Perl libraries in the same way as for Python. Doesn't
really need to be a function, since there's only one perlPackages in
nixpkgs, but I went for consistency with the python plugin.
|
| |/ /
| |
| |
| | |
This adds support building with MKL.
|
| |/ |
|
| |\
| |
| | |
release-notes/18-09: add licenses marked as unfree
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|