diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/languages-frameworks/python.section.md | 22 | ||||
| -rw-r--r-- | doc/stdenv/stdenv.chapter.md | 12 |
2 files changed, 29 insertions, 5 deletions
diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md index 53466921887..500f5fa41f3 100644 --- a/doc/languages-frameworks/python.section.md +++ b/doc/languages-frameworks/python.section.md @@ -1632,3 +1632,25 @@ would be: ```ShellSession $ maintainers/scripts/update-python-libraries --target minor --commit --use-pkgs-prefix pkgs/development/python-modules/**/default.nix ``` + +## CPython Update Schedule + +With [PEP 602](https://www.python.org/dev/peps/pep-0602/), CPython now +follows a yearly release cadence. In nixpkgs, all supported interpreters +are made available, but only the most recent two +interpreters package sets are built; this is a compromise between being +the latest interpreter, and what the majority of the Python packages support. + +New CPython interpreters are released in October. Generally, it takes some +time for the majority of active Python projects to support the latest stable +interpreter. To help ease the migration for Nixpkgs users +between Python interpreters the schedule below will be used: + +| When | Event | +| --- | --- | +| After YY.11 Release | Bump CPython package set window. The latest and previous latest stable should now be built. | +| After YY.05 Release | Bump default CPython interpreter to latest stable. | + +In practice, this means that the Python community will have had a stable interpreter +for ~2 months before attempting to update the package set. And this will +allow for ~7 months for Python applications to support the latest interpreter. diff --git a/doc/stdenv/stdenv.chapter.md b/doc/stdenv/stdenv.chapter.md index c108fffd1b0..6d72bd0deb4 100644 --- a/doc/stdenv/stdenv.chapter.md +++ b/doc/stdenv/stdenv.chapter.md @@ -796,7 +796,7 @@ The standard environment provides a number of useful functions. ### `makeWrapper` \<executable\> \<wrapperfile\> \<args\> {#fun-makeWrapper} -Constructs a wrapper for a program with various possible arguments. For example: +Constructs a wrapper for a program with various possible arguments. It is defined as part of 2 setup-hooks named `makeWrapper` and `makeBinaryWrapper` that implement the same bash functions. Hence, to use it you have to add `makeWrapper` to your `nativeBuildInputs`. Here's an example usage: ```bash # adds `FOOBAR=baz` to `$out/bin/foo`’s environment @@ -808,9 +808,11 @@ makeWrapper $out/bin/foo $wrapperfile --set FOOBAR baz makeWrapper $out/bin/foo $wrapperfile --prefix PATH : ${lib.makeBinPath [ hello git ]} ``` -There’s many more kinds of arguments, they are documented in `nixpkgs/pkgs/build-support/setup-hooks/make-wrapper.sh`. +There’s many more kinds of arguments, they are documented in `nixpkgs/pkgs/build-support/setup-hooks/make-wrapper.sh` for the `makeWrapper` implementation and in `nixpkgs/pkgs/build-support/setup-hooks/make-binary-wrapper.sh` for the `makeBinaryWrapper` implementation. -`wrapProgram` is a convenience function you probably want to use most of the time. +`wrapProgram` is a convenience function you probably want to use most of the time, implemented by both `makeWrapper` and `makeBinaryWrapper`. + +Using the `makeBinaryWrapper` implementation is usually preferred, as it creates a tiny _compiled_ wrapper executable, that can be used as a shebang interpreter. This is needed mostly on Darwin, where shebangs cannot point to scripts, [due to a limitation with the `execve`-syscall](https://stackoverflow.com/questions/67100831/macos-shebang-with-absolute-path-not-working). Compiled wrappers generated by `makeBinaryWrapper` can be inspected with `less <path-to-wrapper>` - by scrolling past the binary data you should be able to see the shell command that generated the executable and there see the environment variables that were injected into the wrapper. ### `substitute` \<infile\> \<outfile\> \<subs\> {#fun-substitute} @@ -885,9 +887,9 @@ someVar=$(stripHash $name) ### `wrapProgram` \<executable\> \<makeWrapperArgs\> {#fun-wrapProgram} -Convenience function for `makeWrapper` that automatically creates a sane wrapper file. It takes all the same arguments as `makeWrapper`, except for `--argv0`. +Convenience function for `makeWrapper` that replaces `<\executable\>` with a wrapper that executes the original program. It takes all the same arguments as `makeWrapper`, except for `--inherit-argv0` (used by the `makeBinaryWrapper` implementation) and `--argv0` (used by both `makeWrapper` and `makeBinaryWrapper` wrapper implementations). -It cannot be applied multiple times, since it will overwrite the wrapper file. +If you will apply it multiple times, it will overwrite the wrapper file and you will end up with double wrapping, which should be avoided. ## Package setup hooks {#ssec-setup-hooks} |