Closed srid closed 3 months ago
It probably doesn’t make sense to add non-haskell pkg dependencies in custom, it should only be used for managing haskell packages, which it is meant for.
It made more sense to move hello_rust
to otherOverlays and that did the job: https://github.com/shivaraj-bh/haskell-rust-ffi-template/commit/bb60ff1c510be415d6d24cd4e8bd568a03cf08a1
it should only be used for managing haskell packages, which it is meant for.
If we stick to that, we needn’t worry about the order in which the setting is applied, do we?
People use custom
option to add Haskell dependency too. See https://community.flake.parts/haskell-flake/dependency#nixpkgs
Regarding, otherOvelays
it won't compose like settings
does. So if somebody defines otherOverlays
in their own project, and imports your FFI template (which also defines otherOverlays
), they will get conflict, because of this:
(The reason for preventing merging of overlay lists here is due to nondeterministic semantics of list merge)
It is breaking again after #286
Reproducer:
nix build github:shivaraj-bh/haskell-rust-ffi-template --override-input haskell-flake github:srid/haskell-flake/51bcbc27194e734a1524ac3d36e1539fba9a3baa
@shivaraj-bh It is breaking, but it is not the same error.
From the issue description:
error: attribute 'hello_rust' missing
What I'm seeing when using master
branch:
error: attribute 'override' missing
at /nix/store/fjvkr94j3lwca8y66zccn15rjwzqn0rd-source/pkgs/development/haskell-modules/lib/compose.nix:38:28:
37| */
38| overrideCabal = f: drv: (drv.override (args: args // {
| ^
39| mkDerivation = drv: (args.mkDerivation drv).override f;
Could you open a separate bug report?
Could you open a separate bug report?
Actually, wait. Let me figure out what the issue is first.
Triggered (if not introduced) by #253 which made it so that
buildFromSdist
is applied (alphabetically) before thecustom
option, and for some reasonx: x
in Nix is not lazily propagating the argument.Repro & Details
https://nixos.zulipchat.com/#narrow/stream/413949-haskell-flake/topic/.60custom.60.20setting.20stopped.20working
Proposed design change
Replace
custom
with two setting options:settings.<name>.init : drv
: assigns the initial value before settings are appliedsettings.<name>.final : drv -> drv
: transforms the final drv after the other settings are applied.Open question: putting these two options in the same namespace as other settings is a bit of hack, because they are semantically different. Main questions: a) Is this the best we can do as proposal? b) if so, where should these options live?
(See Zulip for further proposals/ refinements/ ideas)