cargo-init would be super nice

[lightsofapollo]

Something like cargo-init to bootstrap a new project would be very nice (mainly creating the toml file if it does not exist and maybe other flags in the future)

[wycats]

Indeed it would be. On it!

[thiagopnts]

Would it be something like rust-empty or more cargo specific?

[steveklabnik]

@thiagopnts Cargo is a replacement for rust-empty. It would be cargo-specific. My understanding is that rust-empty has a 'transition to Cargo' feature of some kind...

[commonquail]

From the alpha announcement:

• cargo package <name> to create a new package skeleton

Is it correctly understood that cargo package <name> would be the solution to this issue? If so, I associate a different meaning -- that of preparing for distribution -- with package, and I don't think that's an intuitive name for the command. I think init, if for no other reason than consistency with several other tools with similar functionality, is a better fit.

[steveklabnik]

I think we actually decided on cargo project, and that's a typo, but I could be wrong.

[tomjakubowski]

project is a poor choice to me because the other subcommands are all verbs, and "project" as a verb doesn't map well to what this command is doing.

[tomjakubowski]

(unless you mean it's like... a projection of some abstract directory structure onto the filesystem)

[seanmonstar]

+1 cargo init. Previously: npm init?

[thiagopnts]

what about cargo new?

[tomjakubowski]

Prior art includes:

• npm init - creates a package.json file, with interactive prompts for package name/license and such
• lein new [template-name] <project-name> - creates a new folder containing a skeleton project, optionally from a template, including a project.clj file
• cabal init - creates a skeleton Setup.hs and project_name.cabal in the current directory, with interactive prompts

[mavdi]

+1 I miss npm init

[jimfleming]

Just throwing this in, git init would be another established example.

[wycats]

git init initializes an existing directory, as does bundle init. We may want to have an analogue to that and use cargo new to create a new directory that is already cargoified.

[nielsle]

Perhaps allow the user to choose between cargo init --template=bin and cargo init --template=lib to enforce standards.

[steveklabnik]

This should be fixed now, yes?

[alexcrichton]

I'd like to keep this open for now to keep as a reminder for a cargo-init command which takes an existing directory and cargo-ifies it (more complicated though)

[steveklabnik]

I'd vote for cargo new . to do that, but sure.

[andrewrk]

The existing directory case is much more common than the new case. So far every time I've used cargo new it's looked like this (cursing and expletives removed):

~/dev/my-rust-project$ cargo new
Usage:
    cargo new [options] <path>
    cargo new -h | --help
~/dev/my-rust-project$ cargo new .
Destination `~/dev/my-rust-project` already exists
~/dev/my-rust-project$ cargo new my-rust-project
~/dev/my-rust-project$ ls
my-rust-project
$ mv my-rust-project/ ../
mv: overwrite ‘../my-rust-project’? n
~/dev/my-rust-project$ cd ..
~/dev$ mv my-rust-project/ aoeuaoeu
~/dev$ mv aoeuaoeu/my-rust-project/ ./
~/dev$ cp -r aoeuaoeu/* my-rust-project/
~/dev$ rmdir aoeuaoeu/
~/dev$ cd my-rust-project/

Not a positive user experience, to say the least.

[kornelski]

I've ran into this when I wanted to convert a C toy project to rust.

I don't want any fancy autocargoification. I just want a template for Cargo.toml, because I don't remember its syntax.

[ArielCabib]

@andrewrk If you're working under *nix, run

cargo new tmp --bin
mv tmp/Cargo.toml tmp/.git tmp/.gitignore tmp/src .
rmdir tmp

It's ugly, but it works

[andrewrk]

@ArielCabib so, getting the project working at all is not an issue. The issue is that it could be much more straightforward. Hence, this issue filed on the cargo project. Thanks for providing a workaround, but it misses the point.

[shaleh]

Is there opposition to this? I am willing to submit a pull request if it will be accepted.

Do we want cargo new --dir . or is cargo init as suggested above ok?

My work flow looks a lot like @andrewrk's.

[kornelski]

@shaleh is the --dir necessary? I hoped the logic would be that if the argument to new is a path that exists, then filename part of resolved path is used, so that cd foo; cargo new . and cargo new /baz/foo/ create a foo project.

[shaleh]

No it is not needed. It was offered to start the conversation.

On August 29, 2015 5:22:14 AM PDT, Kornel notifications@github.com wrote:

@shaleh is the --dir necessary? I hoped the logic would be that if
the argument to new is a path that exists, then filename part of
resolved path is used, so that cd foo; cargo new . and cargo new /baz/foo/ create a foo project.

---

Reply to this email directly or view it on GitHub:
#21 (comment)

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[rasendubi]

Now when #2081 is merged, this issue can be finally closed?

[alexcrichton]

Thanks for the reminder @rasendubi, and thanks again @vi for the implementation!

[shaleh]

yay!! Bummed my life got in the way but happy someone else stepped in.

[e-oz]

cargo init still can't init project in existing folder, not sure why this issue is closed.

Rust beta 14, macos sierra:

OZ:repositories OZ$ cd feed_importer/
OZ:feed_importer OZ$ cargo init feed_importer --bin --vcs none
OZ:feed_importer OZ$ ls
feed_importer
OZ:feed_importer OZ$ ls feed_importer/
Cargo.toml src

[carols10cents]

@e-oz It looks like you specified a path, but it seems like you wanted to use the current directory. Instead of cargo init feed_importer --bin --vcs none, what if you run cargo init --bin --vcs none?

[e-oz]

@carols10cents I thought I specified package.name. Thank you, without name everything works fine. Sorry for false report.