I wanted to list the different texlive collections using the nix-repl, as per the [manual](https://nixos.org/nixpkgs/manual/#idm140737316065984).
It didn't work, since the nixpkgs were not loaded. Doing `:l <nixpkgs>` first resolved the problem.
This change adds the nixpkgs loading step to the manual so that the next inexperienced person don't have to figure out why it didn't work.
I tested this on NixOS unstable (16.09pre90254.6b20d5b) with nix-repl 1.11.3.
In #19309 a separate output for tkinter was added.
Several dependencies of Python depend indirectly on Python. We have the
following two paths:
```
‘python-2.7.12’ - ‘tk-8.6.6’ - ‘libXft-2.3.2’ - ‘libXrender-0.9.10’ -
‘libX11-1.6.4’ - ‘libxcb-1.12’ - ‘libxslt-1.1.29’- ‘libxml2-2.9.4’ -
‘python-2.7.12’
‘python-2.7.12’ - ‘tk-8.6.6’ - ‘libXft-2.3.2’ - ‘fontconfig-2.12.1’ -
‘dejavu-fonts-2.37’ - ‘fontforge-20160404’ - ‘python-2.7.12’
```
Because only `tkinter` needs this, I added
```
pythonSmall = python.override {x11Support = false;};
```
to break the infinite recursion. We also still have the output
`tkinter`.
However, we might as well build without x11Support by default. Then we build with x11Support as well so we get the tkinter module and put that in a separate package.
`stripHash` documentation states that it prints out the stripped name to
the stdout, but the function stored the value in `strippedName`
instead.
Basically all usages did something like
`$(stripHash $foo | echo $strippedName)` which is just braindamaged.
Fixed the implementation and all invocations.
This is similar to `overrideDerivation`, but overrides the arguments to
`mkDerivation` instead of the underlying `derivation` call.
Also update `makeOverridable` so that uses of `overrideAttrs` can be
followed by `override` and `overrideDerivation`, i.e. they can be
mix-and-matched.
They now go to devman, devdoc, or $outputMan, in that order. This is
to prevent cases such as the man-pages package quietly losing its
section 3 pages.
This one was already merged into release-16.09, so let's not have the
stable branch is ahead of master and confuse things. In addition to
that, currently we have an odd situation that master has less things
actually finished building than in staging.
Conflicts:
pkgs/data/documentation/man-pages/default.nix
This was one of the ways to build packages, we are trying
hard to minimize different ways so it's easier for newcomers
to learn only one way.
This also:
- removes texLive (old), fixes#14807
- removed upstream-updater, if that code is still used it should be in
separate repo
- changes a few packages like gitit/mit-scheme to use new texlive
After #16017 there were a lot
of comments saying that `nix` would be better than `JSON`
for Go packages dependency sets.
As said in https://github.com/NixOS/nixpkgs/pull/16017#issuecomment-229624046
> Because of the content-addressable store, if two programs have the
> same dependency it will already result in the same derivation in
> the
> store. Git also has compression in the pack files so it won't make
> much difference to duplicate the dependencies on disk. And finally
> most users will just use the binary builds so it won't make any
> differences to them.
This PR removes `libs.json` file and puts all package dependencies in
theirs `deps.json`.
* Improve overrideDerivation docs.
Explain how antiquotation in a package's attribute behaves when overriding the package.
* Edit antiquotation note. Fix closing-element.
stripHash uses a global variable to communicate it's computation
results, but it's not necessary. You can just pipe to stdout in a
subshell. A function mostly behaves like just another command.
baseHash() also introduces a suffix-stripping capability since it's
something the users of the function tend to use.
- make line wrapping more consistent (overlong lines)
- don't stress the manual is *only* for contributors,
as it does contain some user-guide parts, including the intro itself
- since March our Hydra publishes binaries immediately,
not waiting for channel update
- missing cd command
- invoke bundler through nix-shell, so it doesn't need to be on $PATH
Note: running bundix through nix-shell won't work ATM, as the shell sets
SSL_CERT_FILE=/no-cert-file.crt which prevents fetching throug https.
- use version from gemset to simplify updating
- don't break line in meta.description
The wrong usage of unfree-redistributable fixed in
ea242619fb can be explaind by unclear
documention, specifically the section in the nixpkgs manual describing
generic licenses it is written to use attributes from `stdenv.lib.licenses`
but in the list the strings form was documented without quotation marks.
This confuses people because the package builds fine locally but failes
the tests on travis-ci.
What I missed when I began using Nix and NixOS was a clear overview of
how packages, channels, Hydra, the master branch and updates to channels
relate to each other.
I've noticed I am not the only one, given the amount of times these
questions pop up.
For now I propose to include this in the Nixpkgs manual, since this
seems to be the best fit. However, I think it would be good to include
this in either a new manual, i.e., a user manual, or an 'official'
tutorial.
It seemed very fine on Hydra before it was cancelled due to glibc rebuild,
in particular the nixpkgs unstable job succeeded except for
bootstrap-tarball tests which should be fine after ee994dfae6.
Therefore, let's avoid another mass rebuild by merging now when we don't
have binaries for master anyway.
* authorization token is optional
* registry url is taken from X-Docker-Endpoints header
* pull.sh correctly resumes partial layer downloads
* detjson.py does not fail on missing keys
This adds changes to the rebar3 expression that patch rebar3 to force it
to be hermetic. Now, by default, rebar3 literally can't download
anything. A 'rebar3-open' expression was added for those folks whe want
the normal rebar3.
This commit adds some very minimial documentation to the Nix
manual. Hopefully, its enough to get someone started and serve as a
first footstep for future documentation writers
There's no change in content except for amending the title of the
section to mention "frameworks", as e.g. I don't consider Qt a language,
and it's likely there will be more of similar cases in future.
To be certain, I checked diff of the generated HTMLs.
