| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
| |
Members of the [package] table in Cargo.toml can be either subtables, or
values like strings and bools. Python is happy to check for membership
of "workspace" in a string, since Python strings are iterables, but if
the value is a bool, Python will throw an exception.
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
fixes build when git dependencies contain symlinks into parent directory
needed for libdeltachat
|
| | |
| |
| |
| | |
is used
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
workspace inheritance
Rust 1.64.0 added support for workspace inheritance, which allows
for crates to inherit values such as dependency version constraints or
package metadata information from their workspaces [0].
This works by having workspace members specify a value as a table, with
`workspace` set to true. Thus, supporting this in importCargoLock is as
simple as walking the crate's Cargo.toml, replacing inherited values
with their workspace counterpart.
This is also what a forthcoming Cargo release will do for `cargo vendor` [1],
but we can get ahead of it ;)
[0]: https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html#cargo-improvements-workspace-inheritance-and-multi-target-builds
[1]: https://github.com/rust-lang/cargo/pull/11414
|
| | |
| |
| |
| |
| |
| | |
Clearer API following the recommendation on the pull request that
introduced this option a few days ago:
https://github.com/NixOS/nixpkgs/pull/221381#discussion_r1141226293
|
| |/
|
|
|
|
| |
This is useful to teach `importCargoLock` how to download crates from a
registry other than crates.io. Specifically, we publish our own crates
to an internal registry and this feature lets us pull from it seamlessly.
|
| |
|
|
|
|
| |
This is to make it possible to implement support for updating
`Cargo.lock`s in nix-update by exposing the path to the `Cargo.lock`
file
|
| |
|
|
|
|
|
|
|
|
|
|
| |
v1 lock files (generated by default by Cargo versions 1.40 and below)
use a single table, `metadata`, to store the checksums of packages.
The primary motivation for doing this now is that we're considering
vendoring all Cargo lock files in Nixpkgs, some packages still use it
(e.g. cargo-asm), and adding support for it doesn't increase the
complexity of the function. No matter the outcome of the vendoring
discussion, this is a nice thing to have because Cargo still supports v1
lock files.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Some crates do not have a Cargo.toml at the top-level, but only in
nested directories. Before this change importCargoLock used to fail with:
error: manifest path `/nix/store/some-store-path/Cargo.toml` does not exist
|
| |
|
|
|
|
|
| |
this mimics the heuristic cargo uses for finding crates in their git
repositories ([cargo-issue-1462]).
[cargo-issue-1462]: https://github.com/rust-lang/cargo/issues/1462
|
| |\
| |
| | |
importCargoLock: introduce alternative parameter `lockFileContents`
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
In restricted mode (and therefore with flakes) `builtins.readFile` may not be the result of `builtins.toFile`,
making it impossible to use a generated lockFile (with or without IFD),
and thereby causing evaluation to fail if `system != builtins.currentSystem` on Hydra
so the jobs are not delegated to eligible build machines that support that system.
This is done in a way that avoids rebuilds.
|
| |/
|
|
|
| |
Previously importCargoLog only recognized git dependencies with `rev =`.
This adds support for git dependencies with `branch =` or `tag =`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
near the end of 2019, the default Cargo.lock format was changed to
[[package]]
checksum = ...
This is what importCargoLock assumes. If the crate had not been `cargo
update`'d with a more recent toolchain than the one with the new
format as default, importCargoLock would fail when trying to access
pkg.checksum.
I ran into such a case (shamefully, in my own crate) and it took me a
while to figure out what was going on, so here is an assert with a
more user friendly message and a hint.
|
|
|
This function can be used to create an output path that is a cargo
vendor directory. In contrast to e.g. fetchCargoTarball all the
dependent crates are fetched using fixed-output derivations. The
hashes for the fixed-output derivations are gathered from the
Cargo.lock file.
Usage is very simple, e.g.:
importCargoLock {
lockFile = ./Cargo.lock;
}
would use the lockfile from the current directory.
The implementation of this function is based on Eelco Dolstra's
import-cargo:
https://github.com/edolstra/import-cargo/blob/master/flake.nix
Compared to upstream:
- We use fetchgit in place of builtins.fetchGit.
- Sync to current cargo vendoring.
|