Home Explore Blog CI



nixpkgs

26th chunk of `doc/languages-frameworks/python.section.md`
122abe93fdab79cb496905f7e547a34bc68237facddb4a0e0000000100000ba5
  If it fails to build on some Python versions, consider disabling them by setting `disable = pythonAtLeast "3.x"` along with a comment.
* The two parameters, `pyproject` and `build-system` are set to avoid the legacy setuptools/distutils build.
* Only unversioned attributes (e.g. `pydantic`, but not `pypdantic_1`) can be included in `dependencies`,
  since due to `PYTHONPATH` limitations we can only ever support a single version for libraries
  without running into duplicate module name conflicts.
* The version restrictions of `dependencies` can be relaxed by [`pythonRelaxDepsHook`](#using-pythonrelaxdepshook).
* Make sure the tests are enabled using for example [`pytestCheckHook`](#using-pytestcheckhook) and, in the case of
  libraries, are passing for all interpreters. If certain tests fail they can be
  disabled individually. Try to avoid disabling the tests altogether. In any
  case, when you disable tests, leave a comment explaining not only _what_ the failure
  is but _why_ the test failure can be ignored for safe distribution with nixpkgs.
* `pythonImportsCheck` is set. This is still a good smoke test even if `pytestCheckHook` is set.
* `meta.platforms` takes the default value in many cases.
  It does not need to be set explicitly unless the package requires a specific platform.
* The file is formatted with `nixfmt-rfc-style`.
* Commit names of Python libraries must reflect that they are Python
  libraries (e.g. `python312Packages.numpy: 1.11 -> 1.12` rather than `numpy: 1.11 -> 1.12`).
* The current default version of python should be included
  in commit messages to enable automatic builds by ofborg.
  For example `python312Packages.numpy: 1.11 -> 1.12` should be used rather
  than `python3Packages.numpy: 1.11 -> 1.12`.
  Note that `pythonPackages` is an alias for `python27Packages`.
* Attribute names in `python-packages.nix` as well as `pname`s should match the
  library's name on PyPI, but be normalized according to [PEP
  0503](https://www.python.org/dev/peps/pep-0503/#normalized-names). This means
  that characters should be converted to lowercase and `.` and `_` should be
  replaced by a single `-` (foo-bar-baz instead of Foo__Bar.baz).
  If necessary, `pname` has to be given a different value within `fetchPypi`.
* It's generally preferable to fetch `src` directly from the repo and not from
  PyPI. Use `fetchPypi` when there's a clear technical reason to do so.
* Packages from sources such as GitHub and GitLab that do not exist on PyPI
  should not use a name that is already used on PyPI. When possible, they should
  use the package repository name prefixed with the owner (e.g. organization) name
  and using a `-` as delimiter.
* Attribute names in `python-packages.nix` should be sorted alphanumerically to
  avoid merge conflicts and ease locating attributes.
* Non-python runtime dependencies should be added via explicit wrapping or
  patching (using e.g. `substituteInPlace`), rather than through propagation via

Title: Python Package Contribution Guidelines (Continued)
Summary
This section continues the guidelines for contributing Python packages to nixpkgs. It covers several aspects: disabling builds for specific Python versions, using 'pyproject' and 'build-system', including only unversioned attributes in 'dependencies', relaxing version restrictions with 'pythonRelaxDepsHook', enabling tests with 'pytestCheckHook', and using 'pythonImportsCheck'. It also mentions that 'meta.platforms' usually takes the default value, formatting with 'nixfmt-rfc-style', Python library commit names, using the current default Python version in commit messages, normalizing PyPI names for attributes and 'pname', fetching sources directly from the repo instead of PyPI, and using a name prefixed with the owner organization for packages not on PyPI, sorting attribute names in `python-packages.nix` alphanumerically, and non-python runtime dependencies should be added via explicit wrapping or patching.