Make `package.name` optional

[epage]

Problem

The primary motivation for this is to close the gap between Cargo.toml and the cargo script experiment (#12207).

For Cargo.toml, package.name is required

For "cargo script", package.name is defaulted to a slug of the file stem.

Proposed Solution

Like with #9829, making this field optional would reduce the specialized documentation around "cargo script". The default for Cargo.toml would be a slug of the parent directory.

Notes

I think there are some other concrete cases that could potentially benefit from this, like rust-lang/rfcs#3452 though I overall see this rarely being relied upon.

[est31]

I'm not sure we'd be able to reduce documentation much here, as the logic to take the filename would not be suiting for Cargo.toml, so we'd have to document that differing logic. We would be able to reduce the overhead of writing existing Cargo.toml files though, which would be a benefit. I'd propose taking the name of the directory the Cargo.toml file is inside.

[epage]

Oops, forgot to specify the parent directory.

While that technically is still a difference, the general concept is the same which makes it easier to teach.

[joshtriplett]

We talked about this in today's @rust-lang/cargo meeting.

People seemed somewhat amenable to this, though we want to discuss it again with @epage present. There were also a few caveats:

• This should prevent cargo publish, just like omitting package.version.
• When we're trying to find a package for a dependency, we shouldn't find a package that doesn't have a name. That would be especially strange for git dependency discovery, but it seemed odd for non-git dependencies as well.
  • With this latter caveat, some folks wondered whether this was successfully improving simplicity; it'd remove a difference between cargo and cargo script, but would add documentation about the restrictions on not having package.name. (This was one of the reasons to wait and re-discuss with @epage present as an advocate for this.)

[epage]

This should prevent cargo publish, just like omitting package.version.

I'm on board with that. Especially when a package is in the root of a repo, one can accidentally change the name of the package and we probably want it pinned.

When we're trying to find a package for a dependency, we shouldn't find a package that doesn't have a name. That would be especially strange for git dependency discovery, but it seemed odd for non-git dependencies as well.

I would be interested in better understanding the concern here.

With this latter caveat, some folks wondered whether this was successfully improving simplicity; it'd remove a difference between cargo and cargo script, but would add documentation about the restrictions on not having package.name

Should these restrictions apply equally to cargo scripts when we add support for them being workspace members, depending on them (most likely as artifact dependencies), or publishing them?

Granted, we don't have to make that decision yet but we'd need to track it to remember for when we do stabilize support for those situations (which wouldn't be considered until after the MVP is stabilized).

[joshtriplett]

We discussed this in today's @rust-lang/cargo meeting. @Eh2406 had a good suggestion for simplifying this further: we could just say that if a crate doesn't have a name, it can't be a dependency.

[epage]

To expand on that and to answer my earlier question on the problems with git dependencies, the issue is when the package is in the root of the repo. In that situation, the name is not under version control and is subject to how the work-dir was checked out. So the problem with publishing a package to a registry equally applies to git and path dependencies. So like Josh said, our publish solution of "don't allow it" could be extended to dependencies. If we don't allow the name-less packages to be discovered in the first place, adding it later would introduce a slight incompatibility because name that might have been unambiguous might become ambiguous. We could consider that the users problem that they created that situation. Or we could allow the package to be discovered by its implicit name but then error on use, bypassing that problem. That error could happen in the Source or in a Lint pass.

If we were to implement git dependency support, it would be trivial as our git discovery code uses our regular manifest loading code and there is no extra work needed to support optional names. If we wanted to make it error when in the root of a repo, that would likely need to be done after manifest loading because the manifest loading code doesn't have knowledge of the git repo root.