I think that's a completely separable proposal; it applies equally to unpublished crates in workspaces, and my current nested packages proposal works with or without it. (Also, I don't think it should be a default version; I think such packages should be able to be actually versionless, and if a version string is necessary it should be filled in with "local" or some other not-semver string. Keep data clean — don't show people version numbers that don't mean anything.)
I was just replying to your idea of the version field being optional with a more concrete approach for it. Technically, it isn't required for this proposal but if private packages need to be version bumped in lockstep, then maintaining this would be a significant burden which would negate some of the benefit.
Granted, I think this proposal could stay agnostic of versioning of nested packages and leave it to the user to decide what to do (lockstep, version=0.0.0, etc)
Today cargo automatically strips dev-dependencies from a package on publish when it is a path dependency without a version requirement. This is helps when dealing with production/test dependency cycles.
We'd have to balance
If start nesting dev-dependencies that were previously stripped, then we've changed behavior
Users aware of this proposal might want their nested/private dependencies for crater, etc
So we'd need to decide which behavior to go with and what the impact on existing / future users is.
Perhaps by analogy with package.include, there should be a package.include_packages manifest field where you list all sub-packages (including further nested ones, since this is controlling this package's publication) that should be published, or a single value like "all" to include all of them. Feels a bit inelegant, but it would also mean there's a simple way to ensure backwards compatibility: if the field is absent, no sub-packages are published.
If we can decide we don't mind the change in behavior (nesting a dev-dependency that was previously dropped) then what we could do to still support it if someone intentionally is trying to drop it is this proposal could respect package.include and package.exclude for private packages. If neither field is explicitly set then we'll take care of it automatically but if either field is set, you need to make sure packages you intend to private are bundled.
As for the cycle use case for dev-dependencies, including a private package shouldn't affect that because the issue is with publish order and since the private package isn't published, that shouldn't be a concern. It just might cause an extra copy of the dependency to be included. We'd need to verify that that doesn't cause problems when a dependency is a normal, registry+path dependency and a dev path dependency.
Maybe we also require private packages to set publish = false?
This seems unintuitive to me. If I write publish = false, I would like that to mean "this package will not ever appear in the public crates.io registry in any form” as it currently does. However, it does suggest another idea: what if the rule is that sub-packages are included if they set a new value publish = "nested" and not otherwise?
This will not only be a way to handle dev-dependencies, but also a way to explicitly distinguish between the three cases of unpublished, nested, and separately-published — preventing the possible mistake of cargo publishing a package that was supposed to be nested.
(And if there is a package.include/package.exclude that conflicts with sub-packages by excluding one that is needed, that should be a verification error at publish time.)
Yes, and given the amount of interest, I am definitely going to write up a Pre-RFC for this, with a more precise description and covering all the cases and alternatives we've discussed.
There have been several ideas in the past around nested crates. A difference here is how simple it is,. relying on a lot of existing behavior to pull this in rather than defining something wholly new. We aren't really adding a new "subcrate" concept but tweaking how we publish crates.
I like the idea. It's a relatively simple change to the crate format, and still less complicated than e.g. cargo's handling of git dependencies.
I think it would need some explicit opt-in, because there already are workspaces with versionless path requirements, and potentially all kinds of publish = X values.