Much like the previous commit that adds dependencies &
optional-dependencies this aligns PEP-517 build systems with how they
are defined in PEP-518/PEP-621.
The naming `build-system` (singular) is aligned with upstream Python standards.
Since https://github.com/NixOS/nixpkgs/pull/161835 we've had the
concept of `passthru.optional-dependencies` for Python optional deps.
Having to explicitly put optional-dependencies in the passthru attrset
is a bit strange API-wise, even though it semantically makes sense.
This change unifies the handling of non-optional & optional Python
dependencies using the names established from PEP-621 (standardized pyproject.toml project metadata).
There is an arbitrary mapping being done right now between
nixpkgs lua infrastructre and luarocks config schema.
This is confusing if you use lua so let's make it possible to use the
lua names in the nixpkgs, thanks to the lib.generators.toLua convertor.
The only nixpkgs thing to remember should be to put the config into `luarocksConfig`
`buildLuarocksPackage.extraVariables` should become `buildLuarocksPackage.luarocksConfig.variables`
Without this change, use overrideAttrs on Ruby
won't change the instance used by Gems, making it
very difficult to build a custom Ruby (e.g. add devdoc).
This changes the non-legacy version of pythonCatchConflictsHook
to recursively scan the output of the target derivation as well
as its propagatedBuildInputs for duplicate dependencies.
Previously, we did scan sys.path but did prove problematic as it
produced false positives i.e. when build-time dependencies of
hooks - such as setuptools in pythonCatchConflictsHook itself -
where mistakenly flagged as duplicates; even though the are
not included in the outputs of the target dervation.
As all python runtime-dependencies are currently passed via
propagatedBuildInputs in nixpkgs, scanning that plus
site-packages seems sufficient to catch all conflicts that
matter at runtime and less likely to produce false positives.
The legacyHook in catch_conflicts_py2.py needs to be migrated
as well, if it's still needed.
it was used only once and complexifies the buildLuarocksPackage function uselessly.
because buildLuarocksPackage accepts ... args, it wont trigger eval failures but this may break out of tree packages where the build can't find the rockspec anymore. Specify the path via `knownRockspec` if that's the case.
