Skip to content
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

Implement cargo init #2081

Merged
merged 1 commit into from
Jan 24, 2016
Merged

Implement cargo init #2081

merged 1 commit into from
Jan 24, 2016

Conversation

vi
Copy link
Contributor

@vi vi commented Oct 26, 2015

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
Copy link

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
Copy link
Contributor Author

vi commented Oct 26, 2015

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

@vi vi changed the title Implement cargo init (#21) Implement cargo init Oct 26, 2015
@alexcrichton
Copy link
Member

Nice work @vi!

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

@alexcrichton alexcrichton assigned alexcrichton and unassigned wycats Oct 28, 2015
Create a new cargo package in current directory

Usage:
cargo init [options]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@vi
Copy link
Contributor Author

vi commented Nov 2, 2015

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

@alexcrichton
Copy link
Member

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

@vi
Copy link
Contributor Author

vi commented Nov 2, 2015

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
Copy link
Member

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
Copy link
Contributor Author

vi commented Nov 4, 2015

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.

pub fn append(path: &Path, contents: &[u8]) -> CargoResult<()> {
(|| -> CargoResult<()> {
let mut f = try!(
OpenOptions::new()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@alexcrichton
Copy link
Member

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

@alexcrichton
Copy link
Member

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".

@alexcrichton alexcrichton added the relnotes Release-note worthy label Jan 23, 2016
@vi
Copy link
Contributor Author

vi commented Jan 23, 2016

Done + rebased yet again.

@alexcrichton
Copy link
Member

@bors: r+ 5e62d85be0259ce198035429e0a9939d30d17d31

Awesome, thanks again @vi!

@bors
Copy link
Collaborator

bors commented Jan 23, 2016

⌛ Testing commit 5e62d85 with merge cc192a3...

@bors
Copy link
Collaborator

bors commented Jan 23, 2016

💔 Test failed - cargo-linux-64

@vi
Copy link
Contributor Author

vi commented Jan 23, 2016

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
Copy link
Contributor Author

vi commented Jan 23, 2016

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

@alexcrichton
Copy link
Member

@bors: r+ 800172f

@bors
Copy link
Collaborator

bors commented Jan 24, 2016

⌛ Testing commit 800172f with merge f052d99...

bors added a commit that referenced this pull request Jan 24, 2016
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
Copy link
Collaborator

bors commented Jan 24, 2016

@bors bors merged commit 800172f into rust-lang:master Jan 24, 2016
@WiSaGaN
Copy link
Contributor

WiSaGaN commented Feb 17, 2016

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

@ticki
Copy link

ticki commented Feb 17, 2016

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

@steveklabnik
Copy link
Member

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
Copy link
Contributor Author

vi commented Feb 17, 2016

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
Copy link
Member

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
Copy link
Contributor Author

vi commented Feb 17, 2016

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
Copy link
Contributor

WiSaGaN commented Feb 17, 2016

@vi
Copy link
Contributor Author

vi commented Feb 17, 2016

It's not that simple.

Restored the function in a proper way: #2390

@alexcrichton
Copy link
Member

@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
Copy link
Contributor Author

vi commented Feb 17, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Release-note worthy
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants