mirror of
https://github.com/NixOS/nixpkgs.git
synced 2025-06-11 04:05:40 +03:00
Merge 73557c22ec
into haskell-updates
This commit is contained in:
commit
e756cc1b5e
3126 changed files with 42257 additions and 25416 deletions
|
@ -195,6 +195,21 @@ Specifies the contents of the `go.sum` file and triggers rebuilds when it change
|
|||
Defaults to `null`
|
||||
|
||||
|
||||
## Versioned toolchains and builders {#ssec-go-toolchain-versions}
|
||||
|
||||
Beside `buildGoModule`, there are also versioned builders available that pin a specific Go version, like `buildGo124Module` for Go 1.24.
|
||||
Similar, versioned toolchains are available, like `go_1_24` for Go 1.24.
|
||||
Both builder and toolchain of a certain version will be removed as soon as the Go version reaches end of life.
|
||||
|
||||
As toolchain updates in nixpkgs cause mass rebuilds and must go through the staging cycle, it can take a while until a new Go minor version is available to consumers of nixpkgs.
|
||||
If you want quicker access to the latest minor, use `go_latest` toolchain and `buildGoLatestModule` builder.
|
||||
To learn more about the Go maintenance and upgrade procedure in nixpkgs, check out the [Go toolchain/builder upgrade policy](https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/go/README.md#go-toolchainbuilder-upgrade-policy).
|
||||
|
||||
::: {.warning}
|
||||
The use of `go_latest` and `buildGoLatestModule` is restricted within nixpkgs.
|
||||
The [Go toolchain/builder upgrade policy](https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/go/README.md#go-toolchainbuilder-upgrade-policy) must be followed.
|
||||
:::
|
||||
|
||||
## Overriding `goModules` {#buildGoModule-goModules-override}
|
||||
|
||||
Overriding `<pkg>.goModules` by calling `goModules.overrideAttrs` is unsupported. Still, it is possible to override the `vendorHash` (`goModules`'s `outputHash`) and the `pre`/`post` hooks for both the build and patch phases of the primary and `goModules` derivation.
|
||||
|
|
|
@ -161,6 +161,27 @@ completely incompatible with packages from `haskellPackages`.
|
|||
|
||||
<!-- TODO(@maralorn) Link to package set generation docs in the contributors guide below. -->
|
||||
|
||||
### GHC Deprecation Policy {#ghc-deprecation-policy}
|
||||
|
||||
We remove GHC versions according to the following policy:
|
||||
|
||||
#### Major GHC versions {#major-ghc-deprecation}
|
||||
|
||||
We keep the following GHC major versions:
|
||||
1. The current Stackage LTS as the default and all later major versions.
|
||||
2. The two latest major versions older than our default.
|
||||
3. The currently recommended GHCup version and all later major versions.
|
||||
|
||||
Older GHC versions might be kept longer, if there are in-tree consumers. We will coordinate with the maintainers of those dependencies to find a way forward.
|
||||
|
||||
#### Minor GHC versions {#minor-ghc-deprecation}
|
||||
|
||||
Every major version has a default minor version. The default minor version will be updated as soon as viable without breakage.
|
||||
|
||||
Older minor versions for a supported major version will only be kept, if they are the last supported version of a major Stackage LTS release.
|
||||
|
||||
<!-- Policy introduced here: https://discourse.nixos.org/t/nixpkgs-ghc-deprecation-policy-user-feedback-necessary/64153 -->
|
||||
|
||||
## `haskellPackages.mkDerivation` {#haskell-mkderivation}
|
||||
|
||||
Every haskell package set has its own haskell-aware `mkDerivation` which is used
|
||||
|
|
|
@ -1259,6 +1259,13 @@ as many tests should be enabled as possible. Failing tests can still be
|
|||
a good indication that the package is not in a valid state.
|
||||
:::
|
||||
|
||||
::: {.note}
|
||||
We only want to test the functionality of a package. In particular, we are not
|
||||
interested in coverage, formatting, and type checking. If pytest fails with
|
||||
`unrecognized arguments: --cov`, add `pytest-cov-stub` to `nativeCheckInputs`
|
||||
rather than `pytest-cov`.
|
||||
:::
|
||||
|
||||
#### Using pytest {#using-pytest}
|
||||
|
||||
Pytest is the most common test runner for python repositories. A trivial
|
||||
|
|
|
@ -605,8 +605,8 @@ In some projects, the Rust crate is not in the main Python source
|
|||
directory. In such cases, the `cargoRoot` attribute can be used to
|
||||
specify the crate's directory relative to `sourceRoot`. In the
|
||||
following example, the crate is in `src/rust`, as specified in the
|
||||
`cargoRoot` attribute. Note that we also need to specify the correct
|
||||
path for `fetchCargoVendor`.
|
||||
`cargoRoot` attribute. Note that we also need to pass in `cargoRoot`
|
||||
to `fetchCargoVendor`.
|
||||
|
||||
```nix
|
||||
{
|
||||
|
@ -627,8 +627,12 @@ buildPythonPackage rec {
|
|||
};
|
||||
|
||||
cargoDeps = rustPlatform.fetchCargoVendor {
|
||||
inherit pname version src;
|
||||
sourceRoot = "${pname}-${version}/${cargoRoot}";
|
||||
inherit
|
||||
pname
|
||||
version
|
||||
src
|
||||
cargoRoot
|
||||
;
|
||||
hash = "sha256-ctUt8maCjnGddKPf+Ii++wKsAXA1h+JM6zKQNXXwJqQ=";
|
||||
};
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue