Home Explore Blog Models CI



nixpkgs

3rd chunk of `doc/languages-frameworks/python.section.md`
e94dff07baca14b289ec3d0c32eaf60f7deb6338ec5791170000000100000fd7
  variable in wrapped programs.
* `pyproject`: Whether the pyproject format should be used. As all other formats
  are deprecated, you are recommended to set this to `true`. When you do so,
  `pypaBuildHook` will be used, and you can add the required build dependencies
  from `build-system.requires` to `build-system`. Note that the pyproject
  format falls back to using `setuptools`, so you can use `pyproject = true`
  even if the package only has a `setup.py`. When set to `false`, you can
  use the existing [hooks](#setup-hooks) or provide your own logic to build the
  package. This can be useful for packages that don't support the pyproject
  format. When unset, the legacy `setuptools` hooks are used for backwards
  compatibility.
* `makeWrapperArgs ? []`: A list of strings. Arguments to be passed to
  [`makeWrapper`](#fun-makeWrapper), which wraps generated binaries. By default, the arguments to
  [`makeWrapper`](#fun-makeWrapper) set `PATH` and `PYTHONPATH` environment variables before calling
  the binary. Additional arguments here can allow a developer to set environment
  variables which will be available when the binary is run. For example,
  `makeWrapperArgs = ["--set" "FOO" "BAR" "--set" "BAZ" "QUX"]`.

  ::: {.note}
  When `__structuredAttrs = false`, the attribute `makeWrapperArgs` is passed as a space-separated string to the build script. Developers should use `prependToVar` or `appendToVar` to add arguments to it in build phases, or use `__structuredAttrs = true` to ensure that `makeWrapperArgs` is passed as a Bash array.

  For compatibility purposes,
  when `makeWrapperArgs` shell variable is specified as a space-separated string (instead of a Bash array) in the build script, the string content is Bash-expanded before concatenated into the `wrapProgram` command. Still, developers should not rely on such behaviours, but use `__structuredAttrs = true` to specify flags containing spaces (e.g. `makeWrapperArgs = [ "--set" "GREETING" "Hello, world!" ]`), or use -pre and -post phases to specify flags with Bash-expansions (e.g. `preFixup = ''makeWrapperArgs+=(--prefix PATH : "$SOME_PATH")`'').
  :::

* `namePrefix`: Prepends text to `${name}` parameter. In case of libraries, this
  defaults to `"python3.8-"` for Python 3.8, etc., and in case of applications to `""`.
* `pypaBuildFlags ? []`: A list of strings. Arguments to be passed to `python -m build --wheel`.
* `pythonPath ? []`: List of packages to be added into `$PYTHONPATH`. Packages
  in `pythonPath` are not propagated (contrary to [`propagatedBuildInputs`](#var-stdenv-propagatedBuildInputs)).
* `preShellHook`: Hook to execute commands before `shellHook`.
* `postShellHook`: Hook to execute commands after `shellHook`.
* `removeBinByteCode ? true`: Remove bytecode from `/bin`. Bytecode is only
  created when the filenames end with `.py`.
* `setupPyGlobalFlags ? []`: List of flags passed to `setup.py` command.
* `setupPyBuildFlags ? []`: List of flags passed to `setup.py build_ext` command.

The [`stdenv.mkDerivation`](#sec-using-stdenv) function accepts various parameters for describing
build inputs (see "Specifying dependencies"). The following are of special
interest for Python packages, either because these are primarily used, or
because their behaviour is different:

* `nativeBuildInputs ? []`: Build-time only dependencies. Typically executables.
* `build-system ? []`: Build-time only Python dependencies. Items listed in `build-system.requires`/`setup_requires`.
* `buildInputs ? []`: Build and/or run-time dependencies that need to be
  compiled for the host machine. Typically non-Python libraries which are being
  linked.
* `nativeCheckInputs ? []`: Dependencies needed for running the [`checkPhase`](#ssec-check-phase). These
  are added to [`nativeBuildInputs`](#var-stdenv-nativeBuildInputs) when [`doCheck = true`](#var-stdenv-doCheck). Items listed in
  `tests_require` go here.
* `dependencies ? []`: Aside from propagating dependencies,
  `buildPythonPackage` also injects code into and wraps executables with the

Title: `buildPythonPackage` Parameters and Dependency Specification
Summary
This chunk continues describing parameters for Nix's `buildPythonPackage` function, covering advanced customization and dependency management. Key parameters include `pyproject` (recommended `true` for modern PEP 517 builds), `makeWrapperArgs` (for `makeWrapper` to set environment variables for wrapped binaries, noting `__structuredAttrs` for arguments with spaces), `namePrefix` (for package naming), `pypaBuildFlags` (for `python -m build --wheel`), `pythonPath` (for non-propagated runtime Python dependencies), `preShellHook`/`postShellHook`, `removeBinByteCode`, and `setupPyGlobalFlags`/`setupPyBuildFlags` (for `setup.py` commands). It also clarifies how `stdenv.mkDerivation` parameters apply to Python packages: `nativeBuildInputs` (build-time executables), `build-system` (Python build dependencies), `buildInputs` (non-Python libraries), `nativeCheckInputs` (test dependencies), and `dependencies` (propagated runtime dependencies).