Customizable suffix for buildDepsOnly

[musjj]

Motivation

My project can be compiled both to native targets and the browser (using buildTrunkPackage). But because of the current hardcoded suffix scheme, it's impossible to distinguish between the native and web dependency derivation in the build logs because they're all labeled as ${pname}-deps.

This can also be annoying when you're cross compiling to multiple targets. You want the dependency to be clearly named (e.g. ${pname}-windows-deps), but the current API makes it really cumbersome to do so.

To address the above issues, this PR makes the following changes:

• You can now override the pnameSuffix in buildDepsOnly.
• buildTrunkPackage now labels the default dependency derivation with -trunk-deps which should improve UX.

Checklist

• added tests to verify new behavior
• added an example template or updated an existing one
• updated docs/API.md (or general documentation) with changes
• updated CHANGELOG.md

[dpc]

Huh. For this reason, I was just modifing then name/pname. So I would have foo foo-web etc.

[musjj]

Yeah that's what I did too, but then you would have to either hardcode the name or redo the crateNameFromCargoToml dance in the derivation.

[dpc]

Probably good idea to have a knob like that anyway.

BTW. Here is the override I use to e.g. add cargo build target & cargo profile to pname.

[ipetkov]

Thanks for the PR! Unfortunately I'm not sure I agree with the direction (of setting the precedent that pnameSuffix should be overridable):

• The point of pnameSuffix is to be something fixed and defined by every direct utility which defines it, that way when you look at the logs you can tell what utility's derivation is running. Its not necessarily meant to disambiguate all derivations across all your various builds and their flavors (by itself at least)
• If we take this idea further and make it so that every utility's pnameSuffix is overridable, then someone setting pnameSuffix = "foobar"; in their commonArgs now suddenly will have -foobar suffixed on every single build which is not very useful
• If you do want to control what your derivations are called (and by extension influence the logs) there's a multitude of options that can be used directly:
  1. mkDerivation requires that either name or the combo of pname/version are defined. But if you set name directly, then pname is entirely ignored (and by extension any pnameSuffix that has been injected)
  2. another option is using (craneLib.buildDepsOnly args).overrideAttrs (old: { pname = lib.removeSuffix "-deps" old.pname; })
  3. Another option is explicitly set your own disambiguator in your builds. E.g. explicitly set pname = "mypkg-trunk"; or pname = "mypkg-native"; which is probably the easiest thing and has other benefits beyond pnameSuffix juggling
  4. (less recommended) you can always mess about with the internals via .overrideScope and tweak the various functions to erase the pnameSuffix or do whatever you'd like (it will be up to you do debug any compatibility hazards from doing so over time)