@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

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

https://discourse.nixos.org/t/prs-already-reviewed/2617/1638

I bumped it onto the master branch, resolved merge conflicts, and revised the release note to use the imperative mood.

@RossComputerGuy The release note entry is inside rl-2405.section.md. Is it okay to backport this PR, or how should I handle the release note entry?

@ShamrockLee I don't think it's too late to backport. Imo, release note entries are not that important for something like this.

Is it okay to backport this PR

I don't think it's too late to backport

I think we should maybe get a second opinion on this; breaking changes are restricted <4 weeks before 24.05's release and changing the clang-tools_* attributes to aliases could be construed as breaking.

Imo, release note entries are not that important for something like this.

I think it's worth having, especially since the intent (as per the OP) is to phase out the aliases that were added.

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

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