Merge branch 'NixOS:master' into master

.github/CODEOWNERS

@@ -387,3 +387,8 @@ pkgs/by-name/lx/lxc*                    @adamcstephens
 /pkgs/os-specific/linux/checkpolicy @RossComputerGuy
 /pkgs/os-specific/linux/libselinux  @RossComputerGuy
 /pkgs/os-specific/linux/libsepol    @RossComputerGuy
+
+# installShellFiles
+/pkgs/by-name/in/installShellFiles/*     @Ericson2314
+/pkgs/test/install-shell-files/*         @Ericson2314
+/doc/hooks/installShellFiles.section.md  @Ericson2314

.github/workflows/update-terraform-providers.yml

@@ -46,7 +46,7 @@ jobs:
         run: |
           git clean -f
       - name: create PR
-        uses: peter-evans/create-pull-request@c5a7806660adbe173f04e3e038b0ccdcd758773c # v6.1.0
+        uses: peter-evans/create-pull-request@8867c4aba1b742c39f8d0ba35429c2dfa4b6cb20 # v7.0.1
         with:
           body: |
             Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.

CONTRIBUTING.md

@@ -354,7 +354,7 @@ The following paragraphs about how to deal with unactive contributors is just a
 Please note that contributors with commit rights unactive for more than three months will have their commit rights revoked.
 -->
 
-Please see the discussion in [GitHub nixpkgs issue #50105](https://github.com/NixOS/nixpkgs/issues/50105) for information on how to proceed to be granted this level of access.
+Please see the discussion in [GitHub nixpkgs issue #321665](https://github.com/NixOS/nixpkgs/issues/321665) for information on how to proceed to be granted this level of access.
 
 In a case a contributor definitively leaves the Nix community, they should create an issue or post on [Discourse](https://discourse.nixos.org) with references of packages and modules they maintain so the maintainership can be taken over by other contributors.
 

doc/build-helpers/fetchers.chapter.md

@@ -157,6 +157,12 @@ Here are security considerations for this scenario:
 
   In more concrete terms, if you use any other hash, the [`--insecure` flag](https://curl.se/docs/manpage.html#-k) will be passed to the underlying call to `curl` when downloading content.
 
+## Proxy usage {#sec-pkgs-fetchers-proxy}
+
+Nixpkgs fetchers can make use of a http(s) proxy. Each fetcher will automatically inherit proxy-related environment variables (`http_proxy`, `https_proxy`, etc) via [impureEnvVars](https://nixos.org/manual/nix/stable/language/advanced-attributes#adv-attr-impureEnvVars).
+
+The environment variable `NIX_SSL_CERT_FILE` is also inherited in fetchers, and can be used to provide a custom certificate bundle to fetchers. This is usually required for a https proxy to work without certificate validation errors.
+
 []{#fetchurl}
 ## `fetchurl` {#sec-pkgs-fetchers-fetchurl}
 

doc/hooks/installShellFiles.section.md

@@ -1,16 +1,79 @@
 # `installShellFiles` {#installshellfiles}
 
-This hook helps with installing manpages and shell completion files. It exposes 2 shell functions `installManPage` and `installShellCompletion` that can be used from your `postInstall` hook.
+This hook adds helpers that install artifacts like executable files, manpages
+and shell completions.
 
-The `installManPage` function takes one or more paths to manpages to install. The manpages must have a section suffix, and may optionally be compressed (with `.gz` suffix). This function will place them into the correct `share/man/man<section>/` directory, in [`outputMan`](#outputman).
+It exposes the following functions that can be used from your `postInstall`
+hook:
 
-The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh).
+## `installBin` {#installshellfiles-installbin}
+
+The `installBin` function takes one or more paths to files to install as
+executable files.
+
+This function will place them into [`outputBin`](#outputbin).
+
+### Example Usage {#installshellfiles-installbin-exampleusage}
+
+```nix
+{
+  nativeBuildInputs = [ installShellFiles ];
+
+  # Sometimes the file has an undersirable name. It should be renamed before
+  # being installed via installBin
+  postInstall = ''
+    mv a.out delmar
+    installBin foobar delmar
+  '';
+}
+```
+
+## `installManPage` {#installshellfiles-installmanpage}
+
+The `installManPage` function takes one or more paths to manpages to install.
+
+The manpages must have a section suffix, and may optionally be compressed (with
+`.gz` suffix). This function will place them into the correct
+`share/man/man<section>/` directory in [`outputMan`](#outputman).
+
+### Example Usage {#installshellfiles-installmanpage-exampleusage}
+
+```nix
+{
+  nativeBuildInputs = [ installShellFiles ];
+
+  # Sometimes the manpage file has an undersirable name; e.g. it conflicts with
+  # another software with an equal name. It should be renamed before being
+  # installed via installManPage
+  postInstall = ''
+    mv fromsea.3 delmar.3
+    installManPage foobar.1 delmar.3
+  '';
+}
+```
+
+## `installShellCompletion` {#installshellfiles-installshellcompletion}
+
+The `installShellCompletion` function takes one or more paths to shell
+completion files.
+
+By default it will autodetect the shell type from the completion file extension,
+but you may also specify it by passing one of `--bash`, `--fish`, or
+`--zsh`. These flags apply to all paths listed after them (up until another
+shell flag is given). Each path may also have a custom installation name
+provided by providing a flag `--name NAME` before the path. If this flag is not
+provided, zsh completions will be renamed automatically such that `foobar.zsh`
+becomes `_foobar`. A root name may be provided for all paths using the flag
+`--cmd NAME`; this synthesizes the appropriate name depending on the shell
+(e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for
+zsh).
+
+### Example Usage {#installshellfiles-installshellcompletion-exampleusage}
 
 ```nix
 {
   nativeBuildInputs = [ installShellFiles ];
   postInstall = ''
-    installManPage doc/foobar.1 doc/barfoo.3
     # explicit behavior
     installShellCompletion --bash --name foobar.bash share/completions.bash
     installShellCompletion --fish --name foobar.fish share/completions.fish
@@ -21,9 +84,17 @@ The `installShellCompletion` function takes one or more paths to shell completio
 }
 ```
 
-The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided (see below).
+The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which
+case the shell and name must be provided (see below).
+
+If the destination shell completion file is not actually present or consists of
+zero bytes after calling `installShellCompletion` this is treated as a build
+failure. In particular, if completion files are not vendored but are generated
+by running an executable, this is likely to fail in cross compilation
+scenarios. The result will be a zero byte completion file and hence a build
+failure. To prevent this, guard the completion generation commands.
 
-If the destination shell completion file is not actually present or consists of zero bytes after calling `installShellCompletion` this is treated as a build failure. In particular, if completion files are not vendored but are generated by running an executable, this is likely to fail in cross compilation scenarios. The result will be a zero byte completion file and hence a build failure. To prevent this, guard the completion commands against this, e.g.
+### Example Usage {#installshellfiles-installshellcompletion-exampleusage-guarded}
 
 ```nix
 {

doc/languages-frameworks/dotnet.section.md

@@ -93,7 +93,7 @@ The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given
 To package Dotnet applications, you can use `buildDotnetModule`. This has similar arguments to `stdenv.mkDerivation`, with the following additions:
 
 * `projectFile` is used for specifying the dotnet project file, relative to the source root. These have `.sln` (entire solution) or `.csproj` (single project) file extensions. This can be a list of multiple projects as well. When omitted, will attempt to find and build the solution (`.sln`). If running into problems, make sure to set it to a file (or a list of files) with the `.csproj` extension - building applications as entire solutions is not fully supported by the .NET CLI.
-* `nugetDeps` takes either a path to a `deps.nix` file, or a derivation. The `deps.nix` file can be generated using the script attached to `passthru.fetch-deps`. If the argument is a derivation, it will be used directly and assume it has the same output as `mkNugetDeps`.
+* `nugetDeps` takes either a path to a `deps.nix` file, or a derivation. The `deps.nix` file can be generated using the script attached to `passthru.fetch-deps`. For compatibility, if the argument is a list of derivations, they will be added to `buildInputs`.
 ::: {.note}
 For more detail about managing the `deps.nix` file, see [Generating and updating NuGet dependencies](#generating-and-updating-nuget-dependencies)
 :::

doc/languages-frameworks/index.md

@@ -67,6 +67,7 @@ dotnet.section.md
 emscripten.section.md
 gnome.section.md
 go.section.md
+gradle.section.md
 hare.section.md
 haskell.section.md
 hy.section.md

doc/languages-frameworks/javascript.section.md

@@ -258,34 +258,79 @@ It returns a derivation with all `package-lock.json` dependencies downloaded int
 
 #### importNpmLock {#javascript-buildNpmPackage-importNpmLock}
 
-`importNpmLock` is a Nix function that requires the following optional arguments:
+This function replaces the npm dependency references in `package.json` and `package-lock.json` with paths to the Nix store.
+How each dependency is fetched can be customized with the `fetcherOpts` argument.
 
-- `npmRoot`: Path to package directory containing the source tree
+This is a simpler and more convenient alternative to [`fetchNpmDeps`](#javascript-buildNpmPackage-fetchNpmDeps) for managing npm dependencies in Nixpkgs.
+There is no need to specify a `hash`, since it relies entirely on the integrity hashes already present in the `package-lock.json` file.
+
+##### Inputs {#javascript-buildNpmPackage-inputs}
+
+- `npmRoot`: Path to package directory containing the source tree.
+  If this is omitted, the `package` and `packageLock` arguments must be specified instead.
 - `package`: Parsed contents of `package.json`
 - `packageLock`: Parsed contents of `package-lock.json`
 - `pname`: Package name
 - `version`: Package version
+- `fetcherOpts`: An attribute set of arguments forwarded to the underlying fetcher.
 
 It returns a derivation with a patched `package.json` & `package-lock.json` with all dependencies resolved to Nix store paths.
 
-This function is analogous to using `fetchNpmDeps`, but instead of specifying `hash` it uses metadata from `package.json` & `package-lock.json`.
+:::{.note}
+`npmHooks.npmConfigHook` cannot be used with `importNpmLock`.
+Use `importNpmLock.npmConfigHook` instead.
+:::
+
+:::{.example}
+
+##### `pkgs.importNpmLock` usage example {#javascript-buildNpmPackage-example}
+```nix
+{ buildNpmPackage, importNpmLock }:
+
+buildNpmPackage {
+  pname = "hello";
+  version = "0.1.0";
+  src = ./.;
+
+  npmDeps = importNpmLock {
+    npmRoot = ./.;
+  };
 
-Note that `npmHooks.npmConfigHook` cannot be used with `importNpmLock`. You will instead need to use `importNpmLock.npmConfigHook`:
+  npmConfigHook = importNpmLock.npmConfigHook;
+}
+```
+:::
+
+:::{.example}
+##### `pkgs.importNpmLock` usage example with `fetcherOpts` {#javascript-buildNpmPackage-example-fetcherOpts}
+
+`importNpmLock` uses the following fetchers:
+
+- `pkgs.fetchurl` for `http(s)` dependencies
+- `builtins.fetchGit` for `git` dependencies
+
+It is possible to provide additional arguments to individual fetchers as needed:
 
 ```nix
 { buildNpmPackage, importNpmLock }:
 
 buildNpmPackage {
   pname = "hello";
   version = "0.1.0";
+  src = ./.;
 
   npmDeps = importNpmLock {
     npmRoot = ./.;
+    fetcherOpts = {
+      # Pass 'curlOptsList' to 'pkgs.fetchurl' while fetching 'axios'
+      { "node_modules/axios" = { curlOptsList = [ "--verbose" ]; }; }
+    };
   };
 
   npmConfigHook = importNpmLock.npmConfigHook;
 }
 ```
+:::
 
 #### importNpmLock.buildNodeModules {#javascript-buildNpmPackage-importNpmLock.buildNodeModules}
 

doc/languages-frameworks/python.section.md

@@ -374,6 +374,50 @@ mkPythonMetaPackage {
 }
 ```
 
+#### `mkPythonEditablePackage` function {#mkpythoneditablepackage-function}
+
+When developing Python packages it's common to install packages in [editable mode](https://setuptools.pypa.io/en/latest/userguide/development_mode.html).
+Like `mkPythonMetaPackage` this function exists to create an otherwise empty package, but also containing a pointer to an impure location outside the Nix store that can be changed without rebuilding.
+
+The editable root is passed as a string. Normally `.pth` files contains absolute paths to the mutable location. This isn't always ergonomic with Nix, so environment variables are expanded at runtime.
+This means that a shell hook setting up something like a `$REPO_ROOT` variable can be used as the relative package root.
+
+As an implementation detail, the [PEP-518](https://peps.python.org/pep-0518/) `build-system` specified won't be used, but instead the editable package will be built using [hatchling](https://pypi.org/project/hatchling/).
+The `build-system`'s provided will instead become runtime dependencies of the editable package.
+
+Note that overriding packages deeper in the dependency graph _can_ work, but it's not the primary use case and overriding existing packages can make others break in unexpected ways.
+
+``` nix
+{ pkgs ? import <nixpkgs> { } }:
+
+let
+  pyproject = pkgs.lib.importTOML ./pyproject.toml;
+
+  myPython = pkgs.python.override {
+    self = myPython;
+    packageOverrides = pyfinal: pyprev: {
+      # An editable package with a script that loads our mutable location
+      my-editable = pyfinal.mkPythonEditablePackage {
+        # Inherit project metadata from pyproject.toml
+        pname = pyproject.project.name;
+        inherit (pyproject.project) version;
+
+        # The editable root passed as a string
+        root = "$REPO_ROOT/src"; # Use environment variable expansion at runtime
+
+        # Inject a script (other PEP-621 entrypoints are also accepted)
+        inherit (pyproject.project) scripts;
+      };
+    };
+  };
+
+  pythonEnv =  testPython.withPackages (ps: [ ps.my-editable ]);
+
+in pkgs.mkShell {
+  packages = [ pythonEnv ];
+}
+```
+
 #### `python.buildEnv` function {#python.buildenv-function}
 
 Python environments can be created using the low-level `pkgs.buildEnv` function.

doc/languages-frameworks/ruby.section.md

@@ -154,7 +154,7 @@ let
     defaultGemConfig = pkgs.defaultGemConfig // {
       pg = attrs: {
         buildFlags =
-        [ "--with-pg-config=${pkgs."postgresql_${pg_version}"}/bin/pg_config" ];
+        [ "--with-pg-config=${lib.getDev pkgs."postgresql_${pg_version}"}/bin/pg_config" ];
       };
     };
   };
@@ -172,7 +172,7 @@ let
     gemConfig = pkgs.defaultGemConfig // {
       pg = attrs: {
         buildFlags =
-        [ "--with-pg-config=${pkgs."postgresql_${pg_version}"}/bin/pg_config" ];
+        [ "--with-pg-config=${lib.getDev pkgs."postgresql_${pg_version}"}/bin/pg_config" ];
       };
     };
   };
@@ -190,9 +190,7 @@ let
         defaultGemConfig = super.defaultGemConfig // {
           pg = attrs: {
             buildFlags = [
-              "--with-pg-config=${
-                pkgs."postgresql_${pg_version}"
-              }/bin/pg_config"
+              "--with-pg-config=${lib.getDev pkgs."postgresql_${pg_version}"}/bin/pg_config"
             ];
           };
         };

doc/languages-frameworks/rust.section.md

@@ -567,8 +567,7 @@ buildPythonPackage rec {
   };
 
   cargoDeps = rustPlatform.fetchCargoTarball {
-    inherit src sourceRoot;
-    name = "${pname}-${version}";
+    inherit pname version src sourceRoot;
     hash = "sha256-miW//pnOmww2i6SOGbkrAIdc/JMDT4FJLqdMFojZeoY=";
   };
 
@@ -611,9 +610,8 @@ buildPythonPackage rec {
   };
 
   cargoDeps = rustPlatform.fetchCargoTarball {
-    inherit src;
+    inherit pname version src;
     sourceRoot = "${pname}-${version}/${cargoRoot}";
-    name = "${pname}-${version}";
     hash = "sha256-PS562W4L1NimqDV2H0jl5vYhL08H9est/pbIxSdYVfo=";
   };
 
@@ -652,8 +650,7 @@ buildPythonPackage rec {
   };
 
   cargoDeps = rustPlatform.fetchCargoTarball {
-    inherit src;
-    name = "${pname}-${version}";
+    inherit pname version src;
     hash = "sha256-heOBK8qi2nuc/Ib+I/vLzZ1fUUD/G/KTw9d7M4Hz5O0=";
   };
 
@@ -697,8 +694,7 @@ stdenv.mkDerivation rec {
   };
 
   cargoDeps = rustPlatform.fetchCargoTarball {
-    inherit src;
-    name = "${pname}-${version}";
+    inherit pname version src;
     hash = "sha256-8fa3fa+sFi5H+49B5sr2vYPkp9C9s6CcE0zv4xB8gww=";
   };
 

lib/fetchers.nix

@@ -9,6 +9,9 @@
     # by definition pure.
     "http_proxy" "https_proxy" "ftp_proxy" "all_proxy" "no_proxy"
     "HTTP_PROXY" "HTTPS_PROXY" "FTP_PROXY" "ALL_PROXY" "NO_PROXY"
+
+    # https proxies typically need to inject custom root CAs too
+    "NIX_SSL_CERT_FILE"
   ];
 
 }

lib/licenses.nix

@@ -554,6 +554,13 @@ lib.mapAttrs mkLicense ({
     redistributable = true;
   };
 
+  fsl11Asl20 = {
+    fullName = "Functional Source License, Version 1.1, Apache 2.0 Future License";
+    url = "https://fsl.software/FSL-1.1-Apache-2.0.template.md";
+    free = false;
+    redistributable = true;
+  };
+
   ftl = {
     spdxId = "FTL";
     fullName = "Freetype Project License";