boost: Split python module into separate derivation

[tobim]

This change replaces the enablePython option from the boost package into a more granular structure where boost-python is a dedicated derivation. This is enabled by 2 new passthru functions from the boost attribute:

• boost.pythonLib: Takes a python derivation as a parameter and produces a boost-python itself.
• boost.withPython: Takes a python derivation as well and produces a symlinkJoin-style derivation containing a boost-python lib together with the rest of the boost libraries.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

• boost.withPython: Takes a python derivation as well and produces a symlinkJoin-style derivation containing a boost-python lib together with the rest of the boost libraries.

Is this a convenience, or actually required to deal with some build systems? I would prefer to skip it if the former.

I like the idea of splitting it. I wonder if it makes sense to scope it under python3Packages rather than passing a Python as an argument? But since this isn’t itself a Python library, I guess that might not make sense.

cc @natsukium as Python maintainer

[emilazy]

Would be nice to avoid duplication here.

[tobim]

I'm not so sure. The last 8 are indeed duplicate, but intrucing a b2Args_common indirection would hurt readability and I'd expect them to change very infrequently.

[tobim]

• boost.withPython: Takes a python derivation as well and produces a symlinkJoin-style derivation containing a boost-python lib together with the rest of the boost libraries.

Is this a convenience, or actually required to deal with some build systems? I would prefer to skip it if the former.

Depends on how you define convenience, without that some packages would need to be patched to support boost libs that are spread out across multiple filesystem paths. I believe I only used it for packages that actually need it.

I like the idea of splitting it. I wonder if it makes sense to scope it under python3Packages rather than passing a Python as an argument? But since this isn’t itself a Python library, I guess that might not make sense.

There is actually a boost-python attribute in python3Packages as an alias for boost.pythonLib python now. If you need a non-default boost-python you still need to go through the top-level boost attribute tho.

[tobim]

@natsukium @emilazy @SuperSandro2000 I think this is ready. I'd like to get it merged soon.

[SuperSandro2000]

I do not know if this falls under a potential breaking change and we still can merge it for the release.

[tobim]

Let's merge this after branch off.