Workspace use means libtock-core has more dependencies than necessary.

[jrvanwhy]

I stumbled upon this issue while trying to update tock-on-titan to the current libtock-rs master commit.

Because test_runner and libtock-core are in the same workspace, cargo searches for test_runner's dependencies when it tries to build libtock-core. This makes async-std a build dependency of libtock-core.

I don't think this was either expected or intended behavior when PR #164 created libtock-core.

This is blocking the tock-on-titan update because tock-on-titan's build system (intentionally) makes it difficult to pull in large dependencies such as async-std. I can think of a few ways forward:

1. Remove the workspace entirely, making each crate stand on its own.
2. Change the directory layout so that libtock-core stays outside the "main" workspace. We could potentially have multiple workspaces, such as one for minimal-dependency code (e.g. libtock-core) and another for high-dependency code (libtock-rs and test_runner).
3. Leave the workspace in place and let out-of-tree boards deal with it. This is possible for tock-on-titan (our build system could copy libtock-core to a separate directory, removing it from the workspace) but is not possible for cargo-based projects.

I would prefer option 1 or 2, but I'd like to hear what others think before I put too much effort into this change.

[alistair23]

It's just a build dependency right? It's not included in the actual binary?

[jrvanwhy]

It's just a build dependency right? It's not included in the actual binary?

Correct.

[torfmaster]

I would prefer a 2-ish solution as workspaces make it easy to let tests run for all crates and to be sure that all of the code checked in compiles. Moreover, it makes refactorings easy for people who use IDEs.

[torfmaster]

My overall favorite would be publishing the crates to crates.io and not bothering downstream users with the git repository.

[jrvanwhy]

My overall favorite would be publishing the crates to crates.io and not bothering downstream users with the git repository.

That makes it difficult for downstream users (e.g. tock-on-titan) to contribute back upstream, so I would be opposed to that solution.

[jrvanwhy]

I can't reproduce the issue any more. I suspect this was either operator error (perhaps I edited one binary's Cargo.toml then tried to build a different binary?) or a Cargo.lock caching issue.

Regardless, closing this issue.