`cargo package` (and publish) includes `target` folder

[eirnym]

Problem

Per documentation, target folder is excluded from package.

let's test it:

$ cargo init t
$ cd t
$ git init . && git add .* * && git commit -m "initial commit"
$ cargo package
$ find target/package/t-0.1.0/target

1. It builds the target (default profile on localhost is dev)
2. It includes files from target

First point is concerning, because I don't trust any build process enough to share secrets with it. Even if on CI you cannot call remote, secrets might be embedded into package.

Second point is clear discrepancy with documentation, which states, that target folder is ALWAYS excluded.

Explicit exclude for target folder doesn't work

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

[ehuss]

Thanks for the report! This is normal behavior. The target/package/t-0.1.0/ directory is a scratch directory where cargo extracts the generated package and runs cargo build to verify the package is still working. This has the side-effect of creating a target directory. You can avoid this with the --no-verify flag.

[eirnym]

I see, thank you for information. I request to document packaging behaviour explicitly by outlining whole process, rather than imply that user will eventually find and read RFC (if it exists)

[eirnym]

Also I'd like to not build it once more time, as on CI it's a common and recommended practice to build package and run tests before run the package, but it's important to verify that all required metadata is present

[ehuss]

The packaging behavior is documented at https://doc.rust-lang.org/cargo/commands/cargo-package.html with an outline of all the steps. Is there something there that seems to be missing?

I'm not sure I understand your second comment. If you don't want to build it when packaging or publishing, there is a --no-verify flag to skip that.

[eirnym]

The default behaviour (build to verify) is not documented.

In the second statement I'd like to have an option to verify by CI rules (not written in Cargo.toml
) that all (to selected?) metadata is present, but I don't want to build package once more because I've already built package and tested it on a line before.

I understand the default rules, but I'd like to modify them

[weihanglo]

The default behaviour (build to verify) is not documented.

It is documented as I see it:

3. Extract the .crate file and build it to verify it can build.
   • This will rebuild your package from scratch to ensure that it can be built from a pristine state. The --no-verify flag can be used to skip this step.

Mind sharing your suggestion what is missing?

In the second statement I'd like to have an option to verify by CI rules (not written in Cargo.toml) that all (to selected?) metadata is present, but I don't want to build package once more because I've already built package and tested it on a line before.
I understand the default rules, but I'd like to modify them

Sorry I don't quite understand. Could you expand a bit what the option you're looking for "verifying by CI rules"? With --no-verify you should be able to skip the extra compilation and the metadata check is still there. The metadata check can be turned off by the --no-metadata flag otherwise.

[eirnym]

@weihanglo thank you for a response.

I concentrated on first two phases, so missed this part in documentation. Nevertheless, I still see target folder under target/package/<pkg>-<version> as redundant and misleading if it isn't used for publishing.

---

Verification process consists in 2 phases: metadata verification (warning only) and build. I'd like to turn off build phase (per reasons I've described above), but keep metadata verification. Additionally, I'd like to enforce metadata to be filled, so it won't be a warning.

Could you please suggest an approach to achieve this goal?

[weihanglo]

Nevertheless, I still see target folder under target/package/-

The cargo package manual focuses on the .crate tarball, and also says it would build it. I understand your confusion, though .crate is the exact output artifact users should look at. The manual could say that target/package/foo-1.0.0/ is the folder extracted from the foo-1.0.0.crate tarball, though I feel like it is an implementation detail we don't want to talk about in man page.

I'd like to enforce metadata to be filled, so it won't be a warning.

That sounds pretty much related to #12235, which user could have controls over warnings emitted by Cargo. Let me link this from there.

Anything beyond above we can help with?

[eirnym]

I'd like to verify my cargo workspace before packaging but without building.

At the moment cargo clippy tells nothing about missing fields on freshly-created project and I have to rely on cargo package to at least observe warning.

On the other hand I don't (and won't) trust build process and code enough to allow access to any secrets in any environment.

[weihanglo]

Thanks for the info, @eirnym.

tells nothing about missing fields on freshly-created project and I have to rely on cargo package to at least observe warning.
…
I'd like to enforce metadata to be filled, so it won't be a warning.

Do you want to submit a new issue for tracking this, and close this one? It is also fine if you want to update the title and the description of this issue.