Init transparently (was: Rustlings command should mirror cargo command as far as possible)

[daniel-pfeiffer]

New Proposal

Thinking more about this, why have an annoying extra step to init in the first place? The user experience would be smoother, if it would just start!

There would be 3 cases to handle:

• already in directory, just go. Like: cargo run
• directory exists as sub-directory, cd there internally and go. Like: cargo -C rustlings run
• directory not found near here, init it transparently, cd there internally and go. Like: cargo new rustlings; cargo -C rustlings run

Original Proposal

Cargo has two near identical commands new and init. They both do exactly the same thing. (But apparently implemented twice, because the message differs a bit.) Additionally only init has a 2nd behaviour, when not given an argument.

Confusingly rustlings init is different to that! Since backwards compatibility is hardly important, I suggest to align with cargo like this:

• rustlings init (re-)initialises the current directory (to avoid pain for people already used to old behaviour, maybe only if it is empty or contains Cargo.toml)
• rustlings new creates the directory rustlings
• rustlings init <NAME> and rustlings new <NAME> create a new directory <NAME>

[mo8it]

I want users to understand that everything is contained in the new directory and they should cd into it and open an editor there before working on the exercises.

Rustlings isn't Cargo. I appreciate you trying to make things less confusing in the ecosystem, but I don't think that rustlings new makes sense with Rustlings since the user does the initialization only once. It would also be very confusing to allow to provide a custom name for the Rustlings directory.