Cargo stashes unused patches into a special section of the Cargo.lock
file:
```
[[patch.unused]]
name = "uuid"
version = "1.4.1"
source = "git+https://github.com/uuid-rs/uuid#50f70278de02c106650b8d6deb325dd59b5f2a24"
```
... a section that we, currently, don't read.
Ignoring that section causes the build to fail because even if the patch
is unused, when the source is unavailable, Cargo tries to fetch it
(which, understandably, is not possible inside the sandbox).
This commit extends our logic so that we download both the "used" and
"unused" dependencies.
Closes https://github.com/nix-community/naersk/issues/308.
This commit fixes a bug introduced in #276 where symlinked Cargo.tomls
wouldn't get detected due to readDir() reporting them as - well -
_symlinks_ instead of regular files.
Note that we continue to keep the `if type == "directory"` condition for
recursion which means that we'll fail to detect "nested" Cargo.tomls if
someone decides to go wild and create workspace with symlinked crates.
That I'm not 100% sure on how to approach, but fortunately cases like
those seem to be practically non-existent (and Crane apparently not
supporting them builds a bit of confidence here as well).
Closes#280.
Our current Cargo.toml discovery algorithm is based on reading the main
Cargo.toml and looking at its `workspace.members` - unfortunately, as it
turns out there's actually no requirement for all workspace crates to be
listed there, and some applications do fancy things like:
```toml
[workspace]
members = [ "crates/foo" ]
[dependencies]
foo = { path = "crates/foo" }
bar = { path = "crates/bar" } # whoopsie
```
... which doesn't play nice with Naersk's incremental builds (that is,
the compilation fails unless `singleStep = true;` is turned on).
This commit changes the logic to use a different approach: now we simply
recursively scan the root directory, noting down all the Cargo.tomls we
find; Crane seems to use the same algorithm.
I think the only case where this approach falls short are spurious
Cargo.tomls that are present somewhere in the source directory but are
actually unused - for instance, imagine I'm writing a Cargo clone where
I've got files like `src/tests/broken-manifest/Cargo.toml` - in cases
like these, the current approach will cause the build to fail, because
we will try to fixup a broken Cargo.toml, thinking it's used somewhere.
We could try to handle cases like these by using an even different
approach: instead of traversing the source tree, we could load the main
Cargo.toml and traverse its `workspace.members` + all path-based
dependencies recursively, noting down all the *explicitly present*
Cargo.tomls.
That is, given a top-level manifest of:
```
[workspace]
members = [ "crates/foo" ]
[dependencies]
foo = { path = "crates/foo" }
bar = { path = "crates/bar" }
```
... we'd note down and load `crates/foo/Cargo.toml` +
`crates/bar/Cargo.toml`, and then load _their_ path-based dependencies,
to find all transitive Cargo.tomls that belong to this workspace.
(that is, we have to scan the crates recursively, because `bar` might
depend on `crates/zar` - and that's not an imaginary edge case, that's
actually what happens inside Nushell, for instance.)
I don't have enough time to implement this more extensive approach now,
and IMO the improvement presented here is still an improvement, so I
think it's safe to go with the new-but-still-subpar approach here and
consider the better algorithm in the future :-)
# Testing
All tests pass, I've also made sure that incremental builds are still
incremental.
Closes https://github.com/nix-community/naersk/issues/274
Prevent use of allRefs when nix <2.4 is in use.
nix <2.4 does not accept the `allRefs` flag, but has `allRefs` behavior
by default. Note that this goes beyond the the initial intent of this
PR because it enables naersk's `gitAllRefs` flag to work on nix <2.4.
The usage of git "rev" dependencies in Cargo implies that the rev
will be found regardless of ref. This is currently not true in naersk;
the following dependency fails:
usbfs = {git = "https://github.com/goertzenator/usbfs-rs", rev = "7c35b46e41ad76f838cd99b493f9337f475b5b70"}
During compilation, we build two derivations - one for the dependencies
and another for the user's crate itself. Passing `postInstall` to
`buildPackage` pass-throughs it into both derivations, which is not what
most users would probably expect.
This commit adds `postInstall` as an explicit configuration option (so
that it's neatly documented), zeroing it out for the dependencies-only
derivation.
I don't think there's any use case for something like `postInstallDeps`,
so it's not introduced here.
Closes https://github.com/nix-community/naersk/issues/237
