generate workspace dependencies

[xxchan]

Cargo now supports specify workspace.dependencies. Is it possible for cargo-hakari to generate workspace.dependencies so that workspace-hack isn't needed anymore? 🤔

https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html#cargo-improvements-workspace-inheritance-and-multi-target-builds

[sunshowers]

Thanks for the question! There seem to be two parts to this:

1. Do workspace dependencies mean feature unification is no longer important?

As far as I can tell, defining workspace dependencies doesn't obviate the need for workspace-hack. Since not every crate enables every workspace dependency, feature unification might still result in different feature sets for different workspace crates through transitive dependencies.

Thus, in order to serve the goals of hakari, some sort of extra feature unification is still going to be necessary.

2. Can cargo-hakari write to the workspace dependency list rather than to a separate workspace-hack package?

As far as I can tell, this is infeasible as well. There are two big reasons for it, in my mind:

1. Merge conflicts become an even bigger problem than today. Currently, hakari uses .gitattributes to configure the workspace-hack's Cargo.toml as a binary file. This is so that we don't write conflict markers, which would cause cargo to choke, and thus would mean that you'd no longer be able to run cargo-hakari to regenerate the Cargo.toml.

   This is a feasible approach since the workspace-hack's Cargo.toml is a mostly generated file. However, trying to do this with the workspace's main Cargo.toml is fraught with peril -- making it a binary file would violate expectations, while treating it as a text file would routinely break cargo and hakari.

2. You can't mass-import dependencies from the workspace list. For every dependency, cargo-hakari would have to write out, to every workspace package:

   [dependencies]
   dep1.workspace = true
   dep2.workspace = true
   dep3.workspace = true

   This means that hakari's footprint is going to be far greater than a single workspace-hack-enabling line in every package.

Because of these two issues, I believe that the current implementation is still the best one even in the face of workspace dependencies. Hope this helps!

[sunshowers]

One improvement that could potentially happen is: what if the workspace-hack Cargo.toml tried to use workspace dependencies as much as possible. That would be an interesting project, though it's not one I plan to work on at the moment.