Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The output from cargo package --list is not good for workspaces #13953

Open
torhovland opened this issue May 23, 2024 · 5 comments
Open

The output from cargo package --list is not good for workspaces #13953

torhovland opened this issue May 23, 2024 · 5 comments
Labels
A-workspaces Area: workspaces C-bug Category: bug Command-package S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@torhovland
Copy link
Contributor

Problem

This issue was discovered when working on #13947, but the problem is also on master.

When run in a workspace root directory, cargo package --list outputs something like this:

Cargo.lock
Cargo.toml
Cargo.toml.orig
src/main.rs
Cargo.toml
Cargo.toml.orig
src/lib.rs

It doesn't indicate that half the files are from one crate, and the other half from another crate.

The question is how to improve this in a way that is backward compatible. It is likely that the current output is used by CI/CD scripts, and should ideally stay as it is when packaging single crates.

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.78.0 (54d8815d0 2024-03-26)
release: 1.78.0
commit-hash: 54d8815d04fa3816edc207bbc4dd36bf18014dbc
commit-date: 2024-03-26
host: aarch64-apple-darwin
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.4.0 (sys:0.4.72+curl-8.6.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 14.2.1 [64-bit]
@torhovland torhovland added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels May 23, 2024
@torhovland
Copy link
Contributor Author

@rustbot label: +Command-package, +A-cli, +S-needs-design

@rustbot rustbot added A-cli Area: Command-line interface, option parsing, etc. Command-package S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. labels May 23, 2024
@weihanglo weihanglo added A-workspaces Area: workspaces and removed S-triage Status: This issue is waiting on initial triage. A-cli Area: Command-line interface, option parsing, etc. labels May 23, 2024
@epage
Copy link
Contributor

epage commented May 23, 2024

This is likely broken enough that we can change behavior. I wonder if we should just error in this case. If we had json output, then I could see specializing the list per package.

@epage
Copy link
Contributor

epage commented May 23, 2024

See #11666 for json output

@torhovland
Copy link
Contributor Author

One approach that is probably better than an error message would be this:

  • In the case of one crate, keep the output as it is.
  • In the case of multiple crates, output the name or full path of each crate followed by its file contents. Let each crate be separated by a blank line.

@epage
Copy link
Contributor

epage commented May 25, 2024

I think a lot depends on what we consider the output intended to be. The current single-crate output is used programmatically. Extending the format with a per-crate header extends what we are offering. This is why I was looking to crate output.

github-merge-queue bot pushed a commit that referenced this issue Dec 31, 2024
### What does this PR try to resolve?

This adds a special case for checking source files are symlinks
and have been modified when under a VCS control

This is required because those paths may link to a file outside the
current package root, but still under the git workdir, affecting the
final packaged `.crate` file.

### How should we test and review this PR?

Pretty similar to #14966, as a part of #14967.

This may have potential performance issue. If a package contains
thousands of symlinks, Cargo will fire `git status` for each of them.
Not sure if we want to do anything proactively now.

The introduction of the `PathEntry` struct gives us more room for
storing file metadata to satisfiy use cases in the future. For
instances,

* Knowing a source file is a symlink and resolving it when packaging on
Windows
  * #5664
  * #14965
* Knowing more about a file's metadata (e.g. permission bits from Git)
  * #4413
  * #8006
* Provide richer information for `cargo package --list`, for example
JSON output mode
  * #11666
  * #13331
  * #13953
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-workspaces Area: workspaces C-bug Category: bug Command-package S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

4 participants