Skip to content

Format Init/New Directory for Cargo.toml and Package Names #15452

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

mewfinity06
Copy link

Format Init/New Directory for Cargo.toml and Package Names

Motivation

This started when I was porting (nob.h)[https://github.com/tsoding/nob.h] to Rust as a fun side project and I named my directory nob.rs before initialization (I like to make my directory first then go in and cargo init it). I got an error saying that . is an illegal char. Wasn't a fan, so I decided to add a function that auto fixes it and still provides the error as a warning (the error on the legality of the parent directory's name)

(This my first PR, so I am sorry if my explanation is not exactly up to par. Thank you in advance for the review!)

Testing

This passes all of the tests for cargo_new and all but one for cargo_init (the one for malformed package name)

TODO

  • Make this an optional command. Perhaps --format-name which would supersede --name <NAME>
  • Add more cases, perhaps substituting certain chars for anything other than _

Issues

The only potential problem with this merge is it would establish how crates must be named. It would not force this format, but push future crates to use the underscore syntax

@rustbot
Copy link
Collaborator

rustbot commented Apr 24, 2025

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added Command-new S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 24, 2025
@epage
Copy link
Contributor

epage commented Apr 24, 2025

I'm sympathetic to the idea of "just make things work" especially for a command like this. We do generally ask that people create issues first. This way we get agreement on the problem and the general solution in a place where people will tend to look for it and the PR focuses on just the implementation.

On the surface, this seems small enough for a go/no-go on just the PR. However, I do think some due diligence should be done to look into why we chose to error especially since we have test cases specifically for this so it was consciously thought about.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Command-new S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants