packaging ripgrep: not all packages build about dream2nix HOT 8 CLOSED

I think this is because dream2nix uses the path dependency source, not the workspace source (eg. it uses ${src}/crates/grep and not ${src}), which means other path dependencies won't be available. It also means that cargo won't be able to access the Cargo.lock, so even if a path dep had no other path deps, it won't build because of that. Adding a getSourceRoot function like described in #83 would fix this.

from dream2nix.

crane will install lib outputs, if there are any. I'm not sure if buildRustPackage does that. These packages don't really have any lib outputs, so nothing is installed.

For example nix-cargo-integration works around these by just disabling all outputs for crates default, and makes you add a metadata value to the package Cargo.toml for enabling outputs for that crate.

But for dream2nix I would say it's better if all packages are outputted by default, for exposure, and then the user should be able to disable them. It seems rather opinionated to not expose packages because of this, which IMO is better expressed with higher abstraction layers. For example, there could be a use case where a crate has no outputs, but it's build.rs will build something and put it in target. This wouldn't be installed by crane or buildRustPackage. I think not exposing that would make the user more confused, because first they'd need to expose that, and then find out their output wasn't installed, as opposed to just finding out their output wasn't installed.

from dream2nix.

I fixed this on #83.

from dream2nix.

This should be fixed by #83 being merged.

from dream2nix.

OK, I checked again and all packages build now. Though all of which I tried don't produce any output (empty ./result).
If I switch to the crane builder, all packages result in ./result/bin/rg.

from dream2nix.

I guess these are all library packages. Does it even make sense to export them? Maybe we should not.

from dream2nix.

They are library packages, so it may not make sense to export them, unless if the user specifically specifies it to be a dynamic library or whatever.

Though IMO this should be left up to the user, so they can just modify the postInstall hook to add anything else they want. They should also be able to filter these packages from the output. Maybe it could be useful to add some arguments to makeFlakeOutputs for this. Eg. exposePackages that takes a list of strings and makes dream2nix only expose the specified packages.

The crane behaviour sounds a bit weird, it's not supposed to build ripgrep on the library packages. I think that is due to crane passing the --workspace flag by default. Will see about overriding the commands for the main derivation so that it is not passed.

from dream2nix.

Though IMO this should be left up to the user, so they can just modify the postInstall hook to add anything else they want.

I'm not quite sure yet about how a use case for this would look like. Let's say someone would want to make a package that should depend upon libraries built with rust, then they would declare the library outputs coming from dream2nix as an input to their derivation, right?

But the result of our build is currently empty. If we want to support that use case then our derivation should have a result/lib a lib output that can be built.

Right now I feel we should probably either provide these lib outputs or not export these derivations.

from dream2nix.