No content was changed, new titles are wrapped with () to signal that
they will need to be decided on in a future commit.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
No content was changed, new titles are wrapped with () to signal that
they will need to be decided on in a future commit.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
No content was changed, new titles are wrapped with () to signal that
they will need to be decided on in a future commit.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
No content was changed, new titles are wrapped with () to signal that
they will need to be decided on in a future commit.
Section in the manual have been preserved with a simple redirect to
GitHub, the proper anchors should be filled out in a future commit once
the new section names are decided.
Zig is still under active development, and new releases often introduce
breaking changes. This makes updating the default version of zig easier.
Some packages did not receive this change because they could be using
the c compiler or linker of zig, which doesn't receive as much breaking
changes compared to e.g. the zig std library.
https://github.com/NixOS/nixpkgs/pull/248243#discussion_r1289401340
This is very useful in conjunction with meta.pkgConfigModules, as the
new tester can use the list provided by this meta attribute as a default
value for moduleNames, making its usage in passthru.tests very
convenient.
For backwards compatibility, a shim under the old name is maintained
with a warning.
* nixpkgs manual, doc Python: render interpreters in a table
The current paragraph presenting Python interpreters is verbose and hinders clarity. The information provided is well suited to be rendered as a table.
Co-authored-by: Shahar "Dawn" Or <mightyiampresence@gmail.com>
* nixpkgs manual, doc Python: fix typos in interpreters' table
* nixpkgs manual, doc Python: update header in interpreters' table
* nixpkgs manual, doc Python: get rid of empty block code workaround in interpreters' table
---------
Co-authored-by: Shahar "Dawn" Or <mightyiampresence@gmail.com>
Conflicts:
- pkgs/tools/networking/shadowfox/default.nix between e989daa65f and 1c29673fcc
- pkgs/tools/networking/wuzz/default.nix between 7d80417710 and 1c29673fcc
In 787af0f79f
I had to change ${go-modules} to $goModules to allow overrideAttrs to work;
However, env vars cannot contain -, so i had to change go-modules too.
This in turn broke nix-update because it uses the go-modules attr.
Instead of making nix-update more complicated, make go-modules naming match cargoDeps.
`fd --type f | xargs sd '\bgo-modules\b' 'goModules'`
and revert change to pkgs/applications/misc/dstask/default.nix
and pkgs/servers/http/dave/default.nix
and pkgs/os-specific/darwin/plistwatch/default.nix
release note added
separating function docs out like this makes it less clear how library
documentation is generated and integrated into the build. if in the
future more parts of nixpkgs use nixdoc it will make sense to have all
information about library doc generation in the same place.
all xml-related tooling can go away. shell.nix is no longer useful since
the makefile is gone and the build runs entirely via a derivation, and
gitignore is thus also no longer that useful. it may filter out some
swap files, but its main reason to exist (keeping generated files out of
a concurrent build of the derivation) has gone away.
also updates nixdoc to 2.3.0. the nixdoc update is not a separate commit
because that would leave the manual build broken for one commit,
potentially breaking bisects and rebases.
nothing except function docs uses this, so we need not expose it. we'll
be reworking this entire section of the build anyway, with the target of
breaking up doc-support as it is now.
Makes overrideAttrs usable in the same way that `override` can be used.
It allows the first argument of `overrideAttrs` to be either a function
or an attrset, instead of only a function:
hello.overrideAttrs (old: { postBuild = "echo hello"; })
hello.overrideAttrs { postBuild = "echo hello"; }
Previously only the first example was possible.
Co-authored-by: adisbladis <adisbladis@gmail.com>
Co-authored-by: matthewcroughan <matt@croughan.sh>
This is actually relatively complicated to achieve, since it involves
overriding GHC on e.g. aarch64-darwin, so the FAQ entry seems warranted.
It's also a good exercise to me, since it demonstrates some problems
with the overriding infrastructure, i.e. that it has a tendency to
inherit the pkgs fixpoint from prev. An example of this problem is
https://github.com/NixOS/nixpkgs/issues/235960, but it has different
manifestations as well. Awareness of this will also help writing the
other sections on overriding.
How complicated it is, seems to be further incentive to go ahead with
https://github.com/NixOS/nixpkgs/pull/239548 as well.
This reverts commit 7e6c518ce4.
I misinterpreted Github's CI failure in the notification tab and
thought that I had broken CI on origin/master, so I panic-reverted
before I merged it (I thought they had).
On closer inspection, it appears that the CI failure was not from
the tip that I merged. This PR resubmits the reverted change. I'll
wait for OfBorg to finish this time.
The manual does an okay job of explaining the rules for each of the
three development branches, but really doesn't give any intuition as
to why there are three (why not four? or two?) or how we got where
we are today.
This commit attempts to fix that, by explaining that there is one
branch that allows mass-rebuild commits, and it has a fast-building
branch both upstream and downstream of it (from the perspective of
automated merges).
I have also removed the term "stabilization" from the arc labels.
This vague term is not defined anywhere, and does communicate any
useful information without a longer explanation. Therefore it is
not appropriate for use in a diagram.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
teutat3s