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
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
When a dependency gets fetched from Git, it's possible for its name to
contain slashes - e.g. because the dependency's branch name contains
one:
```
something-something = { git = "...", branch = "JIRA-123/dev" }
```
Currently, because we don't sanitize those slashes, trying to compile
such `Cargo.toml` / `Cargo.lock` would fail - e.g. given a dependency
from branch `JIRA-123/dev`, we'd try to extract it into path
`JIRA-123/dev` instead of something flat such as `JIRA-123_dev`.
This commit fixes this issue by sanitizing all the `nkey`s - basically,
for all dependency paths, we replace `/` with `_`.
The choice of underscore is arbitrary, just seemed like a good fit.
The git dependencies were indexed by crate name, which is an issue if a dependency is imported through git at various commits. Moreover, if a crate is imported several time at _the same commit_, it is now unpacked only once.
Otherwise builds fail with an error like:
Compiling simple-dep v0.1.0 (/private/var/folders/5h/b11m6fxj2tqgbxwz5bgjy42c0000gn/T/nix-build-some-name.drv-0/dummy-src)
error: couldn't read build.rs: No such file or directory (os error 2)
