```

### How to use Intel’s MKL with numpy and scipy? {#how-to-use-intels-mkl-with-numpy-and-scipy}

MKL can be configured using an overlay. See the section "[Using overlays to
configure alternatives](#sec-overlays-alternatives-blas-lapack)".

### What inputs do `setup_requires`, `install_requires` and `tests_require` map to? {#what-inputs-do-setup_requires-install_requires-and-tests_require-map-to}

In a `setup.py` or `setup.cfg` it is common to declare dependencies:

* `setup_requires` corresponds to `build-system`
* `install_requires` corresponds to `dependencies`
* `tests_require` corresponds to [`nativeCheckInputs`](#var-stdenv-nativeCheckInputs)

### How to enable interpreter optimizations? {#optimizations}

The Python interpreters are by default not built with optimizations enabled, because
the builds are in that case not reproducible. To enable optimizations, override the
interpreter of interest, e.g using

```nix
let
  pkgs = import ./. { };
  mypython = pkgs.python3.override {
    enableOptimizations = true;
    reproducibleBuild = false;
    self = mypython;
  };
in
mypython
```

### How to add optional dependencies? {#python-optional-dependencies}

Some packages define optional dependencies for additional features. With
`setuptools` this is called `extras_require` and `flit` calls it
`extras-require`, while PEP 621 calls these `optional-dependencies`.

```nix
{
  optional-dependencies = {
    complete = [ distributed ];
  };
}
```

and letting the package requiring the extra add the list to its dependencies

```nix
{
  dependencies = [
    # ...
  ]
  ++ dask.optional-dependencies.complete;
}
```

This method is using `passthru`, meaning that changing `optional-dependencies` of a package won't cause it to rebuild.

Note this method is preferred over adding parameters to builders, as that can
result in packages depending on different variants and thereby causing
collisions.

::: {.note}
The `optional-dependencies` attribute should only be used for dependency groups
as defined in package metadata. If a package gracefully handles missing
dependencies in runtime but doesn't advertise it through package metadata, then
these dependencies should not be listed at all. (One may still have to list
them in `nativeCheckInputs` to pass test suite.)
:::

### How to contribute a Python package to nixpkgs? {#tools}

Packages inside nixpkgs must use the [`buildPythonPackage`](#buildpythonpackage-function) or [`buildPythonApplication`](#buildpythonapplication-function) function directly,
because we can only provide security support for non-vendored dependencies.

We recommend [nix-init](https://github.com/nix-community/nix-init) for creating new python packages within nixpkgs,
as it already prefetches the source, parses dependencies for common formats and prefills most things in `meta`.
When using the tool, pull from the original source repository instead of PyPI, if possible.

See also [contributing section](#contributing).

### Are Python interpreters built deterministically? {#deterministic-builds}

The Python interpreters are now built deterministically. Minor modifications had
to be made to the interpreters in order to generate deterministic bytecode. This
has security implications and is relevant for those using Python in a
`nix-shell`.

When the environment variable `DETERMINISTIC_BUILD` is set, all bytecode will
have timestamp 1. The [`buildPythonPackage`](#buildpythonpackage-function) function sets `DETERMINISTIC_BUILD=1`
and [PYTHONHASHSEED=0](https://docs.python.org/3.13/using/cmdline.html#envvar-PYTHONHASHSEED).
Both are also exported in `nix-shell`.

### How to provide automatic tests to Python packages? {#automatic-tests}

It is recommended to test packages as part of the build process.
Source distributions (`sdist`) often include test files, but not always.

The best practice today is to pass a test hook (e.g. pytestCheckHook, unittestCheckHook) into nativeCheckInputs.
This will reconfigure the checkPhase to make use of that particular test framework.