Implement `cargo init` by vi · Pull Request #2081 · rust-lang/cargo

vi · 2015-10-26T00:19:29Z

Implement cargo init command and appropriate tests ( #21).

Features:

Working like cargo new if there are no files in current directory
Auto-detection of --bin
Auto-detection of already existing VSC and appending to respecive ignore file
Appending of appropriate [lib] or [[bin]] section to Cargo.toml in case of some non-standard source locations

Concerns:

I'm not experienced in Rust + lazy => code looks poorer compared to the rest Cargo code
The test don't cover 100% of functions
Project consisting of both binary and library is not handled
Many deviations from previously proposed algorithm

rust-highfive · 2015-10-26T00:19:34Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @wycats (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

vi · 2015-10-26T00:21:35Z

Assignee for my previous attempt was @alexcrichton, but I don't know how to specify assignee when doing pull request here.

Update: found:

r? @alexcrichton

alexcrichton · 2015-10-28T23:37:13Z

Nice work @vi!

I'll see if I can get around to reviewing this tomorrow

alexcrichton · 2015-11-02T17:24:49Z

Perhaps this could take an optional argument of a directory to initialize as well?

I'm not sure how do I make optional positional arguments here. Naive attempt failed.

Ah I think it's possible with [<optional-arg>]

Found out: the main thing that it's a special library (Docopt) is in use and the usage string matters.

vi · 2015-11-02T17:43:23Z

Shall I try to improve things according to line comments or there needs to be major redesign of the feature?

alexcrichton · 2015-11-02T22:56:33Z

Nah I think this is definitely along the right lines, so feel free to make changes in this PR!

vi · 2015-11-02T23:46:14Z

How should the {both lib.rs and main.rs exist} situation be resolved?

Ideally Cargo should create a project file with both [lib] and [[bit]] sections, but that makes edits more substantial (multiple paths to source files, bin can't be just a boolean anymore).

Is support of bin+lib project in cargo init a valid reason to make it complexier? Is it a rare or rather typical case?

alexcrichton · 2015-11-03T17:26:58Z

To me it just seemed a little odd to explicitly deny as it's relatively common. It may require some tweaks of how the implementation goes, but in theory it shouldn't be too onerous I think.

vi · 2015-11-04T04:08:25Z

Implemented updated cargo init:

Multi-target projects are now supported. Error may be thrown now only when it thinks that there are multiple libraries in the project (i.e. both src/lib.rs and lib.rs exist, or lib.rs and foo.rs (without main));
detect_source_paths_and_types is refactored;
Most minor issues described in line comments resolved.

alexcrichton · 2015-11-05T01:26:14Z

This indentation seems a bit off, the OpenOptions should come right after the ( of the try!(

alexcrichton · 2016-01-20T18:05:35Z

(sorry it's being a bit slow...)

alexcrichton · 2016-01-23T01:23:38Z

Thanks for being patient @vi! I talked with @wycats today and we're both quite comfortable moving forward with this. The only lingering thing we thought of is could you tweak the error message for when Cargo.toml already exists? Basically just tailor it to explicitly say "cargo init cannot be run on existing Cargo projects".

vi · 2016-01-23T01:42:24Z

Done + rebased yet again.

alexcrichton · 2016-01-23T04:15:24Z

@bors: r+ 5e62d85be0259ce198035429e0a9939d30d17d31

Awesome, thanks again @vi!

bors · 2016-01-23T04:15:27Z

⌛ Testing commit 5e62d85 with merge cc192a3...

bors · 2016-01-23T04:25:46Z

💔 Test failed - cargo-linux-64

vi · 2016-01-23T12:38:49Z

This test differs from cargo new's test by explicitly not using VCS, hence author name and email don't get extracted from Git and it tries to extract it from system instead, which fails if one unset USER. This function is common in new and init and I expect cargo new to also fail

I can reproduce the failure with

( unset USER; cargo test test_cargo_init )

but not with

( USER= ; cargo test test_cargo_init )

What shall be fixed? Testing tool or cargo_new.rs (which can provide some default unknown author/email)

Update: I see tests do something with .env("USER", now I understand this is probably for reason.

When non-existing directory is provided as argument, it works just like "cargo new". When existing directory is used, it may also create template source file like "cargo new" or may find and use existing source code for Cargo.toml. Squashed commit of the following: cargo init: Supply USER envvar for one test cargo init: Other message when Cargo.toml already exists cargo init: Resolve conflict after with rust-lang#2257 fix minor issues cargo new/init: Simplify error handling code in entry points cargo new/init: Better message for invalid characters in name cargo init: fix minor issues in test cargo init: Avoid excessive builds in the test cargo init: minor fixes cargo init: Skip no_filename test on Windows cargo init: Implement better error message for bin name clash cargo init: minor fixes cargo init: handle "/" path cargo init: Actualise cargo new: Fix upper case error message in test cargo init: Remove paths::{file,directory}_already_exists fix uppper-case error messages cargo init: Fix minor issues per diff comments cargo init: Change binary handling cargo init: Move multiple lib error detection away from mk cargo init: Support optional path argument cargo init: Fix minor issues per Github comments cargo init: Fix complaint from tests/check-style.sh cargo init: Handle projects with multiple mains cargo init: Major refactor, multi-target projects cargo init: Add Cargo.lock unconditionally cargo init: Fix complains from tests/check-style.sh cargo init: Tests for handling VCS cargo init: Handle VCS cargo init: work in progress cargo init: Deduplicate some things between new and init cargo init: Auto-detection of --bin cargo init: work in progress... cargo init: Fix tests and allow explicit --vcs cargo init: intermediate refactor cargo init: First sketch of implementation cargo init: Preliminary test cargo init: first stub See https://github.com/vi/cargo/tree/cargo_init_unsquashed for individual commits

vi · 2016-01-23T12:50:29Z

Fixed the test to have .evn("USER","foo") like other test cases.

alexcrichton · 2016-01-24T18:42:31Z

@bors: r+ 800172f

bors · 2016-01-24T18:42:33Z

⌛ Testing commit 800172f with merge f052d99...

Implement `cargo init` command and appropriate tests ( #21). Features: * Working like `cargo new` if there are no files in current directory * Auto-detection of `--bin` * Auto-detection of already existing VSC and appending to respecive ignore file * Appending of appropriate `[lib]` or `[[bin]]` section to `Cargo.toml` in case of some non-standard source locations Concerns: * I'm not experienced in Rust + lazy => code looks poorer compared to the rest Cargo code * The test don't cover 100% of functions * Project consisting of both binary and library is not handled * Many deviations from [previously proposed algorithm](#2008 (comment))

bors · 2016-01-24T19:08:08Z

☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64

WiSaGaN · 2016-02-17T13:53:44Z

Any reason why cargo new --bin adds Cargo.lock to .gitignore?

ticki · 2016-02-17T14:29:17Z

@WiSaGaN Because Cargo.lock is supposed to be a local file.

steveklabnik · 2016-02-17T14:56:36Z

It should be in the ignore for libraries, but not for binaries.

On Feb 17, 2016, 09:29 -0500, Tickinotifications@github.com, wrote:

@WiSaGaN(https://github.com/WiSaGaN)BecauseCargo.lockis supposed to be a local file.

—
Reply to this email directly orview it on GitHub(#2081 (comment)).

vi · 2016-02-17T14:59:25Z

Is there any reason to include Cargo.lock file in Git repository for binary projects?

Better extra entry in gitignore than missing entry. Project may be recrafted into a library after creation...

steveklabnik · 2016-02-17T15:03:00Z

Yes, for repeatable builds. There's a FAQ entry about this distinction.

On Feb 17, 2016, 09:59 -0500, Vitaly Shukelanotifications@github.com, wrote:

Is there any reason to includeCargo.lockfile in Git repository for binary projects?

Better extra entry in gitignore than missing entry. Project may be recrafted into a library after creation...

—
Reply to this email directly orview it on GitHub(#2081 (comment)).

vi · 2016-02-17T15:18:21Z

Shall I implement again bin/lib distinction for ignore file generation?

Shall the lock file be checked into Git automatically by cargo new/init (in addition to not being added to gitignore) for bin projects?

WiSaGaN · 2016-02-17T15:22:24Z

@vi , yes, please.
Restoring the original should be fine:
https://github.com/rust-lang/cargo/pull/2081/files#diff-149dd4362a3b0dc13b113762713119dfL107

vi · 2016-02-17T15:54:30Z

It's not that simple.

Restored the function in a proper way: #2390

alexcrichton · 2016-02-17T18:48:19Z

@WiSaGaN, @vi, oh oops! I missed that in review by accident, yes it's intentional that bin projects do not ignore Cargo.lock by default

vi · 2016-02-17T18:49:48Z

I remember wondering about whether the condition around adding Cargo.lock is really necessary and recieving something like "Just add it to ignore" reply.

rust-highfive assigned wycats Oct 26, 2015

vi changed the title ~~Implement cargo init (#21)~~ Implement cargo init Oct 26, 2015

alexcrichton assigned alexcrichton and unassigned wycats Oct 28, 2015

alexcrichton reviewed Nov 2, 2015
View reviewed changes

alexcrichton mentioned this pull request Nov 5, 2015

Cargo new in empty dir #2008

Closed

alexcrichton reviewed Nov 5, 2015
View reviewed changes

alexcrichton added the relnotes Release-note worthy label Jan 23, 2016

vi force-pushed the cargo_init branch from ebd2186 to 5e62d85 Compare January 23, 2016 01:42

vi force-pushed the cargo_init branch from 5e62d85 to 800172f Compare January 23, 2016 12:49

bors merged commit 800172f into rust-lang:master Jan 24, 2016

bors mentioned this pull request Jan 24, 2016

Allow licenses to be specified during cargo new #2013

Closed

rasendubi mentioned this pull request Jan 25, 2016

cargo-init would be super nice #21

Closed

Uh oh!

Conversation

vi commented Oct 26, 2015

Uh oh!

rust-highfive commented Oct 26, 2015

Uh oh!

vi commented Oct 26, 2015

Uh oh!

alexcrichton commented Oct 28, 2015

Uh oh!

alexcrichton Nov 2, 2015

Choose a reason for hiding this comment

Uh oh!

vi Nov 4, 2015

Choose a reason for hiding this comment

Uh oh!

alexcrichton Nov 5, 2015

Choose a reason for hiding this comment

Uh oh!

vi Nov 7, 2015

Choose a reason for hiding this comment

Uh oh!

vi commented Nov 2, 2015

Uh oh!

alexcrichton commented Nov 2, 2015

Uh oh!

vi commented Nov 2, 2015

Uh oh!

alexcrichton commented Nov 3, 2015

Uh oh!

vi commented Nov 4, 2015

Uh oh!

alexcrichton Nov 5, 2015

Choose a reason for hiding this comment

Uh oh!

alexcrichton commented Jan 20, 2016

Uh oh!

alexcrichton commented Jan 23, 2016

Uh oh!

vi commented Jan 23, 2016

Uh oh!

alexcrichton commented Jan 23, 2016

Uh oh!

bors commented Jan 23, 2016

Uh oh!

bors commented Jan 23, 2016

Uh oh!

vi commented Jan 23, 2016

Uh oh!

vi commented Jan 23, 2016

Uh oh!

alexcrichton commented Jan 24, 2016

Uh oh!

bors commented Jan 24, 2016

Uh oh!

bors commented Jan 24, 2016

Uh oh!

WiSaGaN commented Feb 17, 2016

Uh oh!

ticki commented Feb 17, 2016

Uh oh!

steveklabnik commented Feb 17, 2016

Uh oh!

vi commented Feb 17, 2016

Uh oh!

steveklabnik commented Feb 17, 2016

Uh oh!

vi commented Feb 17, 2016

Uh oh!

WiSaGaN commented Feb 17, 2016

Uh oh!

vi commented Feb 17, 2016

Uh oh!

alexcrichton commented Feb 17, 2016

Uh oh!

vi commented Feb 17, 2016

Uh oh!

Reviewers

Assignees

Labels