Python components

Specifying dependencies

shellInputs, checkInputs, buildInputs, nativeBuildInputs and propagatedBuildInputs attributes can specified as either a list or a function. In the case of a function the function will be called with the python package set for the current interpreter.

Alternatively the whole set passed to mkLibrary, mkClient, mkComponent and mkService can be a function that gets intersected with the set of python packages for the current interpreter.

buildInputs

buildInputs for python components are dependencies are going to be built and linked. For runtime dependencies use propagatedBuildInputs.

propagatedBuildInputs

Often when making python components you want to put your python dependencies into propagatedBuildInputs. This is because it maps to install_requires in setup.py/setup.cfg. If you put myOwnPythonPackageDependency as a buildInput you would be able to test and run the library locally in the shell but if another package depended on example-lib the other package would get errors because myOwnPythonPackageDependency would be missing.

{ pkgs, base, myOwnPythonPackageDependency }:

base.languages.python.mkLibrary rec {
  name = "example-lib";
  version = "1.0.0";
  src = ./.;
  propagatedBuildInputs = [ myOwnPythonPackageDependency ];
  nativeBuildInputs = pythonPkgs: [ pythonPkgs.setuptools ];
}

Outputs

If the component is setting format to one of setuptools, pyproject or flit it will build a wheel and the derivation will become a multi output derivation with wheel (the wheel) and out (install of the wheel). The wheel output of the python target is also added to the component as a target. If base.languages.python is overridden to be a set of python versions, one output is generated corresponding to each version, and each version have a wheel output. The wheel on the component corresponds to the python target (the default version).

Checks and Config

The installCheckPhase (which is what python uses instead of checkPhase) runs a function called standardTests (can be turned off by setting doStandardTests = false;), this function runs pytest with black, coverage, flake8, mypy, isort and pylint. These tools are wrapped with a config that is generated by merging a default config from Nedryglot with a config for that tool in the component¹. To inspect the resulting config, use the show-generated-config shell command.

Python in Nedryglot exposes a set of hooks, one of which is check which adds all of the above, except adding it to the installCheckPhase. This can be used to add python linting to other types of components.

In case you want to use ruff instead of black, isort, pylint, and flake8, you can set installCheckPhase to ruffStandardTests instead.

Formatting

By default the formatter will follow the selected check variant (ruff or black+isort). However, this can be overridden by setting the formatter attribute to ruff or standard.

Api docs

Nedryglot will output python API docs, by default using Sphinx, the sphinx theme can be set with the config attribute:

[docs.python]
# Currently only supported theme, other than default.
sphinx-theme = "rtd"

# Built-in extensions to activate, `napoleon` is enabled by default.
sphinx-extensions = [ "graphviz" ]

Nedryglot also supports generating docs using pdoc by setting the config

[docs.python]
generator = "pdoc"

Api docs config with docsConfig attribute

Per component docs configuration can be done by settings docsConfig for the python component.

autodocMockImports for sphinx

To avoid errors with autodoc and missing python modules that might not be available when generating the documentation we can set autodocMockImports for the python component as:

base.languages.python.mkLibrary rec {
  ...
  docsConfig = {
    autodocMockImports = [
      "python_module1"
      "python_module2"
    ];
  };
  ...
}