Is there a reason not to include all the tools by default?

e.g. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=waf

Is there a reason not to include all the tools by default?

Only that there are 99 of them, with varying degree of maintenance. Tools are not loaded by default, so even if the quality may vary from tool to tool they shouldn't cause any problems unless a user have a custom tool with the same name.

One additional factor that would support all tools could be that if a custom waf is used, then a custom wafHook would also be needed which would be fine except I didn't manage to override attributes of wafHook so I had to go for a full copy into our overlay (this may simply be a lack of expertise on my part).

If the consensus is to include them all I'd be happy to update the PR. In this case, would it still be ok if I provide the default list of all extra tools in withTools?

See also #62592

Is there a reason not to include all the tools by default?

Only that there are 99 of them, with varying degree of maintenance. Tools are not loaded by default, so even if the quality may vary from tool to tool they shouldn't cause any problems unless a user have a custom tool with the same name.

I've counted 103 and they occupy about 510 Kb. The numbers should not matter too much as they are not loaded at all times. This is a long list of names though, I'm not entirely sure we want to maintain it.

Also it needs to be pointed out that the current state of PR is not a no-op because it removes "compat15" tool that is supposed to be included by default:
https://gitlab.com/ita1024/waf/blob/36898e12affcb9f9bc61a4056377b2bf40f4d2d7/wscript#L110-111

One additional factor that would support all tools could be that if a custom waf is used, then a custom wafHook would also be needed which would be fine except I didn't manage to override attributes of wafHook so I had to go for a full copy into our overlay (this may simply be a lack of expertise on my part).

Looking at the definition of wafHook I could not immediately see the way to override waf without overriding waf globally. I guess we could wrap wafHook implementation with callPackage so that we would be able do wafHook.override { waf = mywaf; }.

If the consensus is to include them all I'd be happy to update the PR. In this case, would it still be ok if I provide the default list of all extra tools in withTools?

Yes, that would be fine.

This is a long list of names though, I'm not entirely sure we want to maintain it.

Agreed. And I wouldn't be able to propose a subset of tools to include either (I only know of the ones we use).

Also it needs to be pointed out that the current state of PR is not a no-op because it removes "compat15" tool that is supposed to be included by default...

Thanks, I also just realized this. I've updated the commit to fix this.

Looking at the definition of wafHook I could not immediately see the way to override waf without overriding waf globally. I guess we could wrap wafHook implementation with callPackage so that we would be able do wafHook.override { waf = mywaf; }.

That would be nice. Is it that straightforward? (I haven't dug into what makeSetupHook does)

Bottom line: Do we want add and maintain the list of extras?

Agreed. And I wouldn't be able to propose a subset of tools to include either (I only know of the ones we use).

Let's abandon this idea for now. Those can be added later if needed.

That would be nice. Is it that straightforward? (I haven't dug into what makeSetupHook does)

It should be very simple. Just copy the definition of wafHook from all-packages to a separate nix file in waf directory, add the function header (something like { makeSetupHook, waf }:) on top, use callPackage to include the definition from the nix file.

@xbreak Thank you!