Skip to content
crate2nix

CHANGELOG

0.14.x - 0.15.0 (unreleased)

  • #359: Document using rust-overlay.

0.14.x - 0.14.1 (2024-06-30)

Maintenance release with cross-compilation fixes, documentation improvements and removal of old workarounds.

  • #352:

    • rust.lib -> stdenv.hostPlatform.rust
    • Always filter src using filterSource
    • Get rid of dontStrip for Darwin as it’s no longer needed
    • Remove no longer needed unsafeDiscardStringContext workaround

  • #351: Set --extra-experimental-features flakes in regenerate_cargo_nix.sh.

  • #350: Document targetFeatures better.

0.13.x - 0.14.0 (2024-04-11)

340 make crate2nix compatible with the lock file changes from rust 1.77.x.

Move sources into /build/sources to maximize compatibility.

0.12.x - 0.13.0

The usual internal version updates but there is more!

Documentation as Github Page

The old README.md had become very long and hard to navigate. Check out the new and shiny page at https://nix-community.github.io/crate2nix/!

Export tools as flake attribute

Do you like to use import from derivation so that you do not have to regenerate Cargo.nix on every dependency change?

The related convenience functions are now also available via the flake attribute “tools”:

# ...
      perSystem = { system, pkgs, lib, inputs', ... }:
        let
          cargoNix = inputs.crate2nix.tools.${system}.appliedCargoNix {
            name = "rustnix";
            src = ./.;
          };
        in
        rec {
          packages.default = cargoNix.rootCrate.build;
        };
# ...

Check out the documentation.

Flakify the crate2nix build itself

Convert the pre-flake infrastructure step-by step to nix flakes, while attempting to preserve compatibility for non-flake users.

This is more of an internal change and should not affect the usage of crate2nix yet but a more flake friendly interface is planned.

Tests and some utilities are still working flake-less but use the flake inputs by default.

0.11.x - 0.12.0

  • Cross compilation fixes. Thank you, @flokli!
  • Propagate crate links attribute. Thank you, @lblasc!
  • Determine target vendor via nixpkgs function. Thank you, @jordanisaacs!
  • Initial flake.nix for crate2nix. Thank you, @vleni!

0.10.x - 0.11.0

Support foo?/bar feature selections

Conditional features are now supported. The feature selection foo?/bar will only enable the bar feature of the foo dependency if that dependency would be enabled anyway (non-optional, or enabled by a different feature selection).

Remove buildRustCrate parameter

This was previously deprecated.

With buildRustCrate removed, this is now possible without running into issues.

Finish renamed dependency support

Previously only renamed dependencies and build-dependencies worked. Now renamed dev-dependencies work also.

Thank you @Fuuzetsu!

Better cross and platform-specific compilation support

  • Rust-style rather than Nixpkgs-style configs are used for [target."some-config"] conditional Cargo sections.

  • The nixpkgs Rust “lib” is used to implement the above and deduplicate other cfg reosolution.

  • Support custom cfg(target_family = "whatever") dependencies.

Fix IFD support library (tools.nix) for Nixpkkgs 22.11

  • See the comment inside there for details.

0.9.x - 0.10.0

Help needed! I don’t have the resources to meaningfully advance this project. Thank you for all the valuable contributions but I’d appreciate a co-maintainer who is motivated to put in some time into reviewing PRs, updating docs, fixing bugs, ..

Warning: This release does not work on Mac OS with a recent nixpkgs. Help wanted. Warning: the buildRustCrate argument will be removed soon.

New “calling convention”

The recommended convention to use Cargo.nix files generated by crate2nix has changed. Instead of callPackage you know should use import:

let cargo_nix = import ./Cargo.nix { inherit pkgs; };
in cargo_nix.workspaceMembers."${your_crate_name}".build

The reason is that the deprecated buildRustPackage argument gets automatically supplied from pkgs.buildRustPackage by pkgs.callPackage. This causes problems when cross compiling.

This was debugged by @symphorien, thank you!

New: Enable optional create feature if sub feature was enabled

Enable a feature with the same name of an optional dependency, if the optional dependency is indirectly enabled by enabling one of its features.

This mimicks the behavior of Cargo which is explained in the note here.

Thank you @pandaman64!

This fixes the following isues:

  • #146 Features fail to contain optional dependencies that got enabled indirectly
  • #182 Can’t build crate with dependency num 0.4.0

New: Customize test commands

Want to customize your test execution? Use the testPreRun and testPostRun crate attributes (next to runTests, see README.md). crate2nix executes the bash snippets in testPreRun and testPostRun directly before and after the actual test command, and in the same shell. Some example use-cases include:

  • Setting some environment variable that is needed for the test.

  • Setting (and then unsetting) the bash set +e option to not fail the derivation build even if a test fails. This is quite useful if your tests are not flaky and you want to cache failures.

Thank you @Fuuzetsu!

0.8.x - 0.9.0

Help needed! I don’t have the resources to meaningfully advance this project. Thank you for all the valuable contributions but I’d appreciate a co-maintainer who is motivated to put in some time into reviewing PRs, updating docs, fixing bugs, ..

Breaking changes

  • Remove long deprecated root_crate and workspace_members aliases in the generated Cargo.nix files.

Enhancements

  • Issue #83 Supporting depending on different versions of the same crate!
  • Some strides towards cross-compilation support. Docs missing and would be appreciated! Thanks, @Ericson2314, @lopsided98!
  • Experimental out-of-tree support — with no time to work further on it :(

Under the hood

  • Test execution is now closer to what cargo test does. Thank you, @symphorien!
  • Better direnv support in the source. Thanks, @Mic92!
  • Better support for upcoming nix 3.0. Thanks, @balsoft!
  • tests: avoid building two versions of the same crate. Thanks, @andir!
  • Remove usages of deprecated stdenv.lib. Thanks, @cole-h!

0.7.x - 0.8.0

Organizational: @andir is now an additional official maintainer of crate2nix. Welcome!

Breaking change:

  • If you are building crates with git dependencies, you will now need to update to a recent version of nixpkgs-unstable. On the upside, crates in sub directories of git repositories will now work!

New features:

  • Issue #53: Search for matching Cargo.toml for git dependencies.
  • Running tests is now documented in the README.
  • Add testInputs to test execution. This allows users to add buildInputs to the test execution. This might be required as during test execution external programs will be called on generated output or in cases where the rust application is just a wrapper around some other tool (in some way or another).
  • Issue #47 Shorter package IDs: Use the crate name or the crate name together with the version as package ID if that is unique. That shortens the generated files, makes them more readable and also strips local paths from the package IDs in most cases. The last point means that you do not have an unncessary diff in you generated Cargo.nix because someone else was regenerating it.

Under the hood:

  • Trimmed down the dependency tree of crate2nix itself by disabling some features.
  • At least some smoke tests for debug functionality.

If you are interested in hacking on crate2nix and buildRustCrate: There are now some convenience flags for the ./run_tests.sh script for offline mode and running the tests against your own modified version of nixpkgs. Check out the README section “Hacking on buildRustCrate in nixpkgs”.

0.6.x - 0.7.1

New features and improvements:

  • Use hashes from Cargo.lock instead of prefetching when available. This should work for any crates.io dependency. :)
  • Follow up to Issue #22 (and others) - Handling of “renamed crates”. Thanks a lot,@andir!
  • Support for multiple binaries from the same crate. Thank you, @kristoff3r!
  • Issue #34 - Support for git prefetching so that repositories with sub modules now work. Thank you, @cpcloud!
  • Issue #65 - Reexpose feature selection parameters from cargo metadata. This allows to include dependencies in the generated build file which are not used for the default features. Or to exclude dependencies for features that you do not care about.
  • Issue #67 - Support for additional lib types - in particular, cdylib. Thank you, @andir! Write a rust library that is used from C code :)
  • Issue #18 - Optional crate unavailable Allows building packages that have multiple versions of the same dependency (with different targets). In particular the flate2 package now builds. Thank you, @cchalmers!
  • Issue #37 - Conditional target expressions for dependencies can now also depend on features. Thank you, @cpcloud!
  • Issue #42 - Some efficiency improvements to prevent stack overflows for projects with huge dependency trees. Thank you, @jamii! * Issue #90 There is a follow up to this: @nagisa was seeing super-linear instantiation counts and provided a flamegraph. @andir proposed a likely fix in nixpkgs. Thank you!
  • Add fuchsia as an unsupported target (ef945396fcb700322b5b5f497a5d243950ed2513 ). Thank you, @jamii!
  • Issue #94: The defaultCrateOverrides argument to the build file has finally the desired effect again.
  • #75: Cleanly separate internal API by internal. attribute path element. Formally, this is no breaking change if it only effects private API but still. I will mitigate by allowing the old paths for a release and issue a warning.

Thank you to everyone who contributed with awesomely detailed issues, PRs or otherwise. You are amazing! Please let me know if I forgot something or forgot to give someone appropriate credit.

For contributors:

  • ./run_tests.sh now makes it easier to prepare your pull requests for review.
  • Build artifacts for linux are now properly pushed to eigenvalue.cachix.org. Adding that cache with cachix will speed up your installations and builds. And it speeds up our CI builds via github actions. Shout out to @domenkozar and other cachix contributors.
  • @alyssais contributed some fixes to the developer scripts, thank you!

Experimental and still undocumented:

  • cargo test-like test running support! Thank you very much for your great work, @andir!

Heads up! Feel free to discuss these planned changes in future releases with me:

  • #77: New/better override behavior that also allows overriding buildRustCrate more easily.
  • #82: Use a new file name for crate-hashes.json every time to prevent merge issues.
  • #102: Convenient support for out-of-tree sources (e.g. for nixpkgs)

0.6.0 - 0.6.1

Backported escaping fix for target expressions.

0.5.1 - 0.6.0

  • Issue #22 - Support renamed crates. Fixed in buildRustCrate in nixpkgs and in crate2nix by PR #24 @danieldk, thanks a lot! This is especially awesome because the popular rand crate recently made use of the “renamed crates” feature and therefore could not be build by buildRustCrate/crate2nix anymore.

  • Issue #15 - Support “overrideCrates” argument for modifying the derivation for a crate by name. Common use case, adding additional buildInputs. NixOS comes with [defaultCrateOverrides](https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/rust/default-crate-overrides.nix) for some common packages already. This is what I use in default.nix of crate2nix to add a conditional dependency under Mac OS:

       cargo_nix.rootCrate.build.override {
          crateOverrides = defaultCrateOverrides // {
            cssparser-macros = attrs: {
              buildInputs = stdenv.lib.optionals stdenv.isDarwin [darwin.apple_sdk.frameworks.Security]; };
          };
        };

    Many thanks to @Profpatsch for pointing to the problem and analyzing it.

  • Issue #43 - Support conditional dependencies using “test” configuration:

    [target.'cfg(test)'.dependencies]
    tracing = { version = "0.1.5", features = ["log"] }

    When building with crate2nix, dependencies will not lead to an error anymore and will simply be ignored (since we do not have test support yet). Thanks to @andir for the nice minimal example!

Infrastructure:

  • I moved the integration tests to tests.nix, they were in rust code before.
  • I also now build every push with github actions, and cachix/cachix-action. A suggestion from @vbrandl in #44. Unfortunately, the rust crates are not cached yet, I think, because they are not in the closure of the result. The cachix caches is called “eigenvalue” for now (I might change that in the future).

0.5.0 - 0.5.1

Don’t use ´Cargo.toml´ but ´Cargo.nix´ as default output! Thank you, @tilpner!

0.4.0 - 0.5.0

Upgrading

  • The default output file changed to “./Cargo.toml”. Specify “-o ./default.nix” explicitly to retain the old default.

Resolved issues

  • Issue #10 - Changing default for -n/--nixpkgs-path to "<nixpkgs>" so that it works by default on NixOS AND Mac OS.
  • Issue #11 - Adding optional dependencies if any of their features is enabled.
  • Issue #14 - Only overwrite output if explicitly specified as output file.

0.3.1 - 0.4.0

Upgrading

Please change references to root_crate to rootCrate.build and references to workspace_members.${crateName} to workspaceMembers.${crateName}.build. The camel case attribute names are in line with the nixos style guide. The .build suffix allows future versions of crate2nix to add other convenient features such as source tarball packages, docker image derivations, … The old aliases still work but are deprecated.

Dynamic feature resolution

The enabled features for a crate now are resolved at build time! That means you can easily override them:

  1. There is a “rootFeatures” argument to the generated build file which you can override when calling it from the command line:

    Terminal window
    nix build -f ....nix --arg rootFeatures '["default" "other"]' rootCrate.build

  2. Or when importing the build file with “callPackage”:

    let cargo_nix = callPackage ./Cargo.nix { rootFeatures = ["default" "other"]; };
        crate2nix = cargo_nix.rootCrate.build;
    in ...;

  3. Or by overriding them on the rootCrate or workspaceMembers:

    let cargo_nix = callPackage ./Cargo.nix {};
        crate2nix = cargo_nix.rootCrate.build.override { features = ["default" "other"]; };
    in ...;

Internal: nix test runner

For this release, I needed substantial amount of nix code so I created some nix unit tests. They are invoked by cargo test like all other tests and live in the ./templates/nix/crate2nix/tests directory.

Feedback: What is needed for a 1.0 release?

I would really appreciate your thoughts. Please add comments to issue #8.

0.3.0 - 0.3.1

Bugfixes

  • Issue #5: Support libPath for proc-macro crates.

Thank you @nuxeh for reporting this bug! Again :)

0.2.1 - 0.3.0

Bugfixes

  • Issue #4: Support for libName != crateName.

Thank you @nuxeh for reporting this bug!

Support for dependencies with git sources

Example:

[dependencies]
"crate2nix" = { git = "https://github.com/kolloch/crate2nix" }

0.2.0 - 0.2.1

  • Added comments to the generated nix build file to indicate which attributes are public and unlikely to change.

0.1.0 - 0.2.0

Bugfixes

  • While the command line help said that the “crate hashes” would be stored in a file called “crate-hashes.json”, it actually used the file “crate_hashes.json” by default. This release uses the documented name which means that after the update nix-prefetch-url might run again.
  • Issue #3: Do not depend on local channel configuration for shell anymore. Instead, we use a recent nixos-unstable because we still need a fix that’s not in stable.

Workspace Support

If crate2nix is applied to a workspace, the resulting nix-file will contain a top-level “workspace_members” attribute set that refers the corresponding top-level crate derivations by name.

Target-specific dependencies

“cfg(…)” expressions and target triplets such as “i686-pc-windows-gnu” are compiled into nix expressions. Support should be reasonable but incomplete because e.g. it does not work for processor features. Please let me know if this causes problems for you!

0.1.0

Initial public release.