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>
It may have to be fetchpatch, fetchpatch2, or fetchurl. We should link somewhere, but we don't have a link target yet, so until then, remove the inaccurate info.
Co-authored-by: Alyssa Ross <hi@alyssa.is>
nixos-render-docs does not support this, and since the examples are
small there isn't that much value in callouts here. change them to
simple MD code blocks and lists instead.
pandoc recognizes `::: note` admonitions, nixos-render-docs only
recognizes `::: {.note}`. surprisingly pandoc also emits the correct
docbook tags for `[](#xref)`s, so we can use that too.
skipping heading levels (eg from # to ###, or starting at ###) is legal
in pandoc, but not in nixos-render-docs. pandoc acts as though section
levels *were* consecutive, nixos-render-docs prefers to tell people not
to do that kind of thing because it can make documents more fragile.
Updates all interpreter references with 3.10/3.11, which are the
current version, that we recurse into for their package set.
Update all code examples with an explicit `format` and expand lists
with multiple items as we do in the python package set. Also set
`pythonImportsCheck` where tests are disabled.
This allows modules that declare their class to be checked.
While that's not most user modules, frameworks can take advantage
of this by setting declaring the module class for their users.
That way, the mistake of importing a module into the wrong hierarchy
can be reported more clearly in some cases.
* doc/default.nix: make the manual build on more than one core
Let's build the manual with more than one core. Maybe people will take better care of it now that it is less painful to build.
* doc/stdenv/meta.chapter.md: document meta.badPlatforms
We don't have any documentation for the `meta.badPlatforms` attribute.
This commit adds documentation for it.
* buildGoModule: don't inherit postBuild hook when building go-modules
This is a slight revert of 5ce647b8bf
(#212800).
Inheriting these hooks in the `.go-modules` derivation can be confusing:
One doesn't expect them to run when generating the fixed output modules
derivation, but only on the main derivation. A `postBuild` hook that
adds some files to $out will cause a very hard to debug issue[1].
This commit adds support for a dedicated `modPostBuild` hook that will
be used only by the derivation building `.go-modules`. Additionally,
`go.section.md` now explains these attributes behavior better.
[1]:
https://discourse.nixos.org/t/cant-update-a-go-package-getting-go-inconsistent-vendoring/27063/6
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
* update.py: introduce subparsers for plugin updaters
This is preliminary work to help create more powerful plugin updaters.
Namely I would like to be able to "just add" plugins without refreshing
the older ones (helpful when github temporarily removes a user from
github due to automated bot detection).
Also concerning the lua updater, we pin some of the dependencies, and I
would like to be able to unpin the package without editing the csv
(coming in later PRs).
* doc/updaters: update command to update editor plugins
including vim, kakoune and lua packages
Co-authored-by: figsoda
Instead of revisions as they should. This is (most-likely) caused by a
simple typo, because Hydra is where the revision should come from, but
it doesn't set `.revision` as the attribute, but rather `.rev`!
There has been a longstanding ambiguity between `broken` and
`badPlatforms`, which seem to serve overlapping purposes.
This commit adds to the documentation two examples of constraints
which cannot be expressed by `platforms` and `badPlatforms`.
This commit also mentions `NIXPKGS_ALLOW_BROKEN=1` for overriding
`broken`.
without stable ids on headings we cannot generate stable links to these
headings. nrd complains about this, but the current docbook workflow
does not.
a few generated ids remain, mostly in examples and footnotes. most of
the examples are generated by nixdoc (which has since gained MD export
functions, and the MD export does generate IDs).
This allows packages that require several dotnet versions to build (like
BeatSaberModManager) to properly depend on the dotnet-sdk specific deps.
This in turns avoids having to regenerate the deps of those packages
after each dotnet-sdk update.
This also changes nuget-to-nix to accept a file with a list of
exclusions instead of a folder.
The headings for the Rust section are structured incorrectly in two ways:
1. The section "Compiling non-Rust packages that include Rust code" is totally specific to `buildRustPackage`. It should be a child of the "Compiling Rust applications with Cargo" section.
1. The section "Setting up `nix-shell`" is totally specific to `buildRustCrate`. It should be a child of the "Compiling Rust crates using Nix instead of Cargo" section.
- Rust
- Compiling Rust applications with Cargo
- ...
- Compiling non-Rust packages that include Rust code
- ...
- Compiling Rust crates using Nix instead of Cargo
- ...
- Setting Up `nix-shell`
- ...
- Rust
- Compiling Rust applications with Cargo
- ...
- Compiling non-Rust packages that include Rust code
- ...
- Compiling Rust crates using Nix instead of Cargo
- ...
- Setting Up `nix-shell`
- ...
The previous approach of trying to make both the `override` mechanism from
`mkDerivation` and the `overrideScope'` mechanism from `newScope` work together
resulted in hard to understand code, and there was a bug where once overridden
packages would lose the changes on next override with `packageOverrides`.
It's not ideal still, because Lisps created by `mkDerivation` will lose their
`pkgs` after using `override`.
The previous approach of manually repeating a complex pattern inside Common Lisp
implementation package declarations was fragile and hard to change. After
reading python and lua modules code in Nixpkgs, I was able to come up with
something better.
The function `wrapLisp` doesn't need to be inside package declarations so all
the code for wrapping Lisps can be in `all-packages.nix`.
This works by wrapping the `override` function created from `mkDerivation` to
accept a new argument `packageOverrides`.
One problem with this is that `override.__functionArgs` disappears. But one can
look at the source code of a package to discover what can be overridden.
It won't be enough to fix cross in all cases, but it is in at least
one: pywayland. I've only made the change in cases I'm confident it's
correct, as it would be wrong to change this when python.interpreter
is used in wrappers, and possibly when it's used for running tests.
these files provided mainly or exclusively xml-related tooling and
support for editing the manual. since docbook is now an implementation
detail (except for still being allowed in option docs, for now) these
tools are no longer necessary, useful, or even functional.
xmlformat.conf is still used by the nixpkgs documentation, so we have to
keep it. there's no reason it can't go live with the nixpkgs docs though.
since support for kbd elements was added with explicit intent in #175128
it seems like a good idea to support this in nixos-render-docs instead
of just dropping it in favor of `*F12*` etc. since it's a very rare
thing in the manual and purely presentational it makes sense to use
bracketed spans instead of a new myst role.
the html-elements.lua plugin is now somewhat misnamed, but it'll go away
very soon so we don't want to bother renaming it.
pandoc drops .title classes when rendering to docbook, so these are
effectively just paragraphs anyway. without support for including them
in a table of contents the complexity of parsing them in
nixos-render-docs won't be warranted.
Running `make -C doc` to build the manual locally leaves .xml artifacts
in the tree. These are ignored by git, but they still get included in
the build when not using flakes, which causes the corresponding chapters
not to be built.
According to the Unicode Standard, you should use U+2019 RIGHT SINGLE
QUOTATION MARK for apostrophes [1]. Before this change, some of the text
in this repo would use U+2018 LEFT SINGLE QUOTATION MARKs instead.
[1]: https://www.unicode.org/versions/Unicode15.0.0/ch06.pdf#G12411
See docs.
Follow-up work:
- Existing packages should be converted
- `defaultPkgConfigPackages` should assert on `meta.pkgConfigModules`
and let `tests.pkg-config` alone test the build results.
CC @sternenseemann
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
The name should end in Array per the current conventions.
This change also contains some minor formatting fixes, as the heading
levels were inconsistent.
- Replace cmdline-tools with tools because tools is obsolete now.
- Depend emulator package to systemImages
androidenv: fix issues on the PR
androidenv: reformat
androidenv: support excluding of `tools` package
androidenv: provide `tools`, and `build-tools`, dependencies
androidenv: replace includeTools with toolsVersion
androidenv: fix a typo
androidenv: add tests to check licenses and installed packages
androidenv: check if tests are running! this commit should fail!
androidenv: fix problems in the review https://github.com/NixOS/nixpkgs/pull/208793
androidenv: add test-suite to handle more tests around
androidenv: fix the test after couldn't running them with ofborg
Update pkgs/development/mobile/androidenv/build-tools.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
androidenv: Resolving https://github.com/NixOS/nixpkgs/pull/208793#discussion_r1065851539
Update pkgs/development/mobile/androidenv/cmdline-tools.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Update pkgs/development/mobile/androidenv/tools.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
androidenv: fix a typo
this converts meta.doc into an md pointer, not an xml pointer. since we
no longer need xml for manual chapters we can also remove support for
manual chapters from md-to-db.sh
since pandoc converts smart quotes to docbook quote elements and our
nixos-render-docs does not we lose this distinction in the rendered
output. that's probably not that bad, our stylesheet didn't make use of
this anyway (and pre-23.05 versions of the chapters didn't use quote
elements either).
also updates the nixpkgs manual to clarify that option docs support all
extensions (although it doesn't support headings at all, so heading
anchors don't work by extension).
Trivial conflict in release notes, except that the xml/docbook parts
are horrible for (semi-)automatic conflict resolution.
Fortunately that's generated anyway.
These are some suggested changes to the new documentation of Haskell in
the Nixpkgs manual. They cover sections until, but excluding, the
section "Available package versions". I am not an English native
speaker, so please correct me and savage these changes!
Also, please let me know if the suggestions are welcome, then I will
continue with the next chapter.
Closes#16182
This improves the error message
Error: _assignFirst found no valid variant!
which occurred when the set of outputs was not sufficient to set
the various outputDev, outputBin, etc variables. Specifically, this
would mean that "out" is not among the outputs, which is valid for
a derivation.
This changes the message to something like
error: _assignFirst: could not find a non-empty variable to assign to outputDev. The following variables were all unset or empty: dev out.
If you did not define an "out" output, make sure to define all the specific required outputs: define an output for one of the unset variables.
While this isn't a full explanation of what stdenv can and can not do,
I think it's vast improvement over the 0 bits of information that it
used to provide. This at least gives a clue as to what's going on, and
even suggests a fix, although probably multiple such fixes are required
in an instance where someone starts with a no-out derivation from scratch
(and decide to persist).
This restarts a Haskell section in the nixpkgs manual. The content
presented here has been written from scratch, although some parts of it
take inspiration from the existing haskell4nix documentation.
It is by no means complete, the idea is mostly to get the ball rolling
in some way. Upcoming tasks are hinted at in the comments in the
documentation file.
matching on only `{...}` does not trigger if the role tag is preceded by
something usually considered a semantic separator that isn't a separator
as markdown knows it, e.g. punctuation characters.
The thunderbird derivation is using `buildMozillaMach` these days,
shared with Firefox and Librefox, so it is probably the correct
, although more complicated, successor.
