Include files of private sub crates (package.publish = false) in the package

[jakwings]

Before #1565 is solved, is it possible to include verbatim copy of all sub crates with config package.publish = false? (excluding the ignored files)

[package]
publish = false
...

[jakwings]

I almost come up with a patch but this line of code gets me down for lack of context:

cargo/src/cargo/util/toml/mod.rs

Line 494 in abd137a

d.path.take(); // path dependencies become crates.io deps

I need to check package.publish and strip the path only if the package is not allowed to be published. Any help?

UPDATE: Alright, I am trying to handle it now.

[est31]

I think the very reason for package.publish = false is to force cargo to not publish stuff.

[jakwings]

@est31 I know. But now people are mixing published sub crates with private sub crates. If cargo insists on publishing all sub crates, then package.publish will become quite useless.

[jakwings]

@est31 Ah, "publish" has two meanings here: a) publish the sub crate to the registry; b) publish the source along with the root crate.

I want to support (b) and forbid (a). Better ideas?

[jakwings]

Ok, the patch is small but the only thing left is local cyclic dependencies. I'm back to #4242

Hope I can sort everything out and apply the logic for package.publish = true too. (well, please see #2064 8-)

UPDATE: Almost done.

[est31]

@iology I don't know but many people type publish = false to prevent their code from being uploaded to crates.io, e.g. because it is proprietary. Now they absolutely don't want it to be uploaded! If now there is a condition like the one you want they'd probably be quite surprised to learn about it. Therefore I don't think this feature should really be added, or if its added it should be enabled by something different than publish=false.

[jakwings]

@est31 Say, root crate A is to be published, and it depends on sub crate B (publish=false, path="./B"), it is reasonable to upload B too, otherwise B should not be placed there. Why would this be a surprise?

[est31]

@iology if you do publish=false for your crate you usually have a strong reason to not get your crate public by accident. It is less about not uploading the crate directly to crates.io. I guess the question boils down to what publish=false should mean.

To give you an use case where this might bite people: maybe crate B is a super secret company crate while crate A is an open source crate that uses B to have some proprietary extensions. Now you want to publish A but you forget to remove the extensions, e.g. because you forgot to switch branches or something. Then you publish it and suddenly B is visible to the world!

[jakwings]

@est31 If you really want to keep those private, you can change the default registry with ./.cargo/config (and for every branch). Since by default publish=true, only you but cargo can make you safer.

Given your extreme use case, I would rather need more than one manifest keys to solve the problem. The real world examples are like this: package A has reusable module1, module2, module3... in their own crates, and crates for tests. It makes people sad that some packages have to make their test crates published to the registry for better modularity.

[est31]

It makes people sad that some packages have to make their test crates published to the registry for better modularity.

It does not make me sad that I won't have to download your test code (which may be quite large) if I just want to build your crate :)

[jakwings]

Maybe you think "publish (to registry)" = "public". I do not. "module=true" could be ok too. I'll come up with a patch.

[jonhoo]

I assume this should be closed given that rust-lang/rfcs#2224 was postponed?