How to work with a forked dependency?

help
1

Hi all,

my project depends on a crate that I needed to fork. Is there any way that I can publish my project that depends on that forked crate, without publishing the forked crate itself?

I don't want to pollute crates.io with a project specific fork. I tried things like local paths and workspaces, but none of them seem to provide a working solution.

Cheers,
Volker

2 Likes
2

AFAIK crates published on crates.io can only depend on other published crates.

The alternative is to use git URLs for your crate and your forked dependency.

3

I wished there was something like a "sub-crate" or "internal-crate", so that I could just bundle my dependencies within my crate without the need to publish the forks.

4

Have you heard about the brand-spanking new [patch] section yet?

Cargo.toml

[package]
# ...
# ...

[workspace]
exclude = ["deps/*"]

[patch]
tempdir = { path = "./deps/tempdir" }

(note: I'm not 100% sure yet what happens when you publish such a project)

2 Likes
5

I've heard of [patch], but I thought it makes sense locally only and not when publishing a crate. I should probably try that out (is there a crates.io staging area for testing purpose?).

6

If it was intended for local configuration I'd expect it to be part of .cargo/config instead.

(yes, this is a thing! Wild how rarely anybody ever mentions it, right? I never even knew it existed until last month)

Sorry, it appears you may be right! They go over the intended usage scenarios in the Specifying Dependencies guide.

The desire to override a dependency or otherwise alter some dependencies can arise through a number of scenarios. Most of them, however, boil down to the ability to work with a crate before it's been published to crates.io. For example:

  • A crate you're working on is also used in a much larger application you're working on, and you'd like to test a bug fix to the library inside of the larger application.
  • An upstream crate you don't work on has a new feature or a bug fix on the master branch of its git repository which you'd like to test out.
  • You're about to publish a new major version of your crate, but you'd like to do integration testing across an entire project to ensure the new major version works.
  • You've submitted a fix to an upstream crate for a bug you found, but you'd like to immediately have your application start depending on the fixed version of the crate to avoid blocking on the bug fix getting merged.

These scenarios are currently all solved with the [patch] manifest section.

That's unfortunate. :confused:

(...although... the last bullet point does sound similar to your use case. At least, in all the ways that should affect how the feature works in cargo)

7

I wonder if my use case is a valid one and if it makes sense to think about possible future solutions. Or if it's just a fixed decision that all crates need to be published on crates.io at all times.

8

Or if it’s just a fixed decision that all crates need to be published on crates.io at all times.

This is rather the impression I get, and is the reason why I don't suspect my "little" project is going anywhere any time soon

[package]
name = "rsp2"
version = "0.1.0"
authors = ["Michael Lamparski <diagonaldevice@gmail.com>"]

[dependencies]

lammps-sys = { path = "src/lammps-sys" }
rsp2-lammps-wrap = { path = "src/lammps-wrap" }
rsp2-tasks = { path = "src/tasks" }
rsp2-minimize = { path = "src/minimize" }
rsp2-phonopy-io = { path = "src/phonopy-io" }
rsp2-array-utils = { path = "src/util/array" }
rsp2-assert-close = { path = "src/util/assert-close" }
rsp2-structure = { path = "src/util/structure" }
rsp2-structure-io = { path = "src/util/structure-io" }
rsp2-slice-math = { path = "src/util/slice-math" }
rsp2-byte-tools-plus-float = { path = "src/util/byte-tools-plus-float" }
rsp2-util-macros = { path = "src/util/macros" }
rsp2-tempdir = { path = "src/util/tempdir" }
rsp2-linalg = { path = "src/math/linalg" }
rsp2-eigenvector-classify = { path = "./src/math/eigenvector-classify" }

# our children who have "graduated"
rsp2-kets = { version = "0.3", git = "https://github.com/ExpHP/rsp2-kets", features = ["serde"] } 
slice-of-array = "0.1"

[workspace]
9

It is a fixed decision. I finally found the right keywords (rust multiple libs in package) and found a thread about having multiple libraries (i.e. crates) in one package (i.e. what you publish on crates.io). The answer is that it was a design decision, hence I don't think that will ever change.

This means that I'll publish the forked crates as <my_package>_<forked_package> (better ideas are welcome).

Edit: I think I name them <my_package>_deps_<forked_package> to make clear that it isn't some sub-crate, but just a dependency.

2 Likes