Cargo: Should `cargo new .` work?

[behnam]

Regularly I fined myself running cargo new ., only to find that I have to move up, delete the newly created directory, and then run cargo new <dir> to have cargo create the dir and do the rest of setup.

Should we allow cargo new . to work in empty directories? Maybe we can even loosen up the conditions later and allow setting up a new cargo project in a directory with existing git setup?

[matklad]

There's cargo init for this use case, but I myself discovered it by accident.

[tobywhughes]

I think cargo init makes more idiomatic sense but I cant think of a reason _not_ to allow it.

_Sent from my Samsung SM-N910P using FastHub_

[behnam]

So, I missed the fact cargo init exists since reading all the intros. Maybe cargo new on an existing directory should give a hint to use cargo init?

[alexcrichton]

Maybe cargo new on an existing directory should give a hint to use cargo init?

Sounds like a great idea to me!

[behnam]

Here's what we have in nightly:

~/code/rust$ cargo new foo
     Created library `foo` project

~/code/rust$ cargo new foo
error: destination `/home/behnam/code/rust/foo` already exists

Use `cargo init` to initialize the directory

~/code/rust$ cargo init foo
error: `cargo init` cannot be run on existing Cargo projects

This LGTM and addresses the issue I brought up here. So, we can close this.