@ofborg build bat-extras.prettybat cloudcompare entwine grass libpulsar nominatim pdal python310Packages.tiledb python39Packages.tiledb qgis qgis-ltr tiledb vscode-extensions.ms-vscode-cpptools

Just seperate those Python scripts to a new output python, so that packages depending on clang-tools won't be forced to have Python in their closures.

It will still be installed as meta.outputsToInstall are set to include "python".

Thank you for your time and patience.

Could it be merged now?

Or should I split the wrapped python script into a new derivation clang-tools-python to reduce the number of rebuild?

The changes look fine to me -- I don't personally have merging rights, though 👀

No wonder. I had thought that all the members have the merging right.

Just make a new derivation clang-tools-python instead. This way, packages depending on clang-tools won't have to rebuild whenever python gets rebuild.

Wrapping the Python scripts into a new package also guarantees zero rebuild of the current packages, and is thus easier to backport.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/1507

Not sure if the change of <pkg>.override interfaces caused by moving clang-tools into llvmPakcages would also be considered backward-incompatible.

oh, good point! here, let's ask:

@wegank This PR changes some top-level attrs to be aliases and changes some package attributes such that existing clang-tools_<ver>.override { ... } invocations may break (now takes clang, libcxxClang instead of llvmPackages). We're wondering if this is okay to backport to 24.05 or if this is considered a breaking change.

I'd consider the change of argument for clang-tools to be breaking. There's also the move to aliases for clang-tools_1{2-8}, which sounds breaking too.

I just rebased the feature branch on top of the master branch and resolved the merge conflict of the release note entries.

Is there anything I could help to push it forward?

I simplified the package calling of clang-tools in each llvmPackages and fixed the evaluation, i.e.

     # Wrapper for standalone command line utilities
-    clang-tools = callPackage ../common/clang-tools {
-      inherit (tools) clang-unwrapped clang libcxxClang;
-      inherit llvm_meta;
-    };
+    clang-tools = callPackage ../common/clang-tools { };

Ok, I rebased it, lets merge this one after CI passes. It's been long due already.

Result of nixpkgs-review pr 191698 run on x86_64-linux 1