feat: Initial support for single-file packages by epage · Pull Request #12245 · rust-lang/cargo (original) (raw)

What does this PR try to resolve?

This is the first step towards #12207. In particular, this focuses on pulling in the demo roughly as-is to serve as a baseline for further PRs. I have a couple months of runtime (multiple times a week) using the version of the demo included here.

How should we test and review this PR?

Commit-by-commit. Most likely, the last (docs) commit should be done first to provide context for the others.

Naming is hard. I came up with these terms just so we can have ways to refer to them. Feedback is welcome.

• -Zscript for this general feature (not great but didn't want to spend too long coming up with a throwaway name)
• "single-file package": Rust code and a cargo manifest in a single file
• "embedded manifest": the explicit manifest inside of a single-file package
• "manifest command": when we interpret cargo <name> as referring to a single-file package, and similar to "built-in commands" and "external commands".

Keep in mind that this is a very hacky solution with many deficiencies and is mostly starting as a baseline for implementing and reviewing those improvements, including

• Switching from regex to syn for extracting manifests for greater resilience
• Matching cargo news logic when sanitizing the inferred package name
• Allowing cargo <name> to also be a Cargo.toml file (for consistency in where manifests are accepted)
• Allowing single-file packages to be used wherever a manifest is accepted

To minimize conflict pain, I would ask that we consider what feedback can be handled in a follow up (though still mention it!). It'll be much easier creating multiple, independent PRs once this baseline is merged to address concerns.

Additional information

The only affect for people on stable is that they may get a warning if they have an external subcommand that will be shadowed when this feature is implemented. This will allow us to collect feedback, without blocking people, so we can have an idea of how "safe" our precedence scheme is for interpreting cargo <name>.

As of right now, aliases with a . in them will be ignored (well, technically their suffix will be exposed as an alias). We directly inject the name into a lookup string into the config that uses . as the separator, so we drill down until we get to the leaf element. Ideally, we would be generating / parsing the lookup key using TOML key syntax so we can better report that this won't be supported after this change :)