-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Implement cargo init
#2081
Conversation
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. |
Assignee for my previous attempt was @alexcrichton, but I don't know how to specify assignee when doing pull request here. Update: found: |
Nice work @vi! I'll see if I can get around to reviewing this tomorrow |
Create a new cargo package in current directory | ||
|
||
Usage: | ||
cargo init [options] |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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>]
There was a problem hiding this comment.
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.
Shall I try to improve things according to line comments or there needs to be major redesign of the feature? |
Nah I think this is definitely along the right lines, so feel free to make changes in this PR! |
How should the {both Ideally Cargo should create a project file with both Is support of bin+lib project in |
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. |
Implemented updated
|
pub fn append(path: &Path, contents: &[u8]) -> CargoResult<()> { | ||
(|| -> CargoResult<()> { | ||
let mut f = try!( | ||
OpenOptions::new() |
There was a problem hiding this comment.
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!(
(sorry it's being a bit slow...) |
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 |
Done + rebased yet again. |
⌛ Testing commit 5e62d85 with merge cc192a3... |
💔 Test failed - cargo-linux-64 |
This test differs from I can reproduce the failure with
but not with
What shall be fixed? Testing tool or Update: I see tests do something with |
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
Fixed the test to have |
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))
☀️ 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 |
Any reason why |
@WiSaGaN Because |
It should be in the ignore for libraries, but not for binaries. On Feb 17, 2016, 09:29 -0500, Tickinotifications@github.com, wrote:
|
Is there any reason to include Better extra entry in gitignore than missing entry. Project may be recrafted into a library after creation... |
Yes, for repeatable builds. There's a FAQ entry about this distinction. On Feb 17, 2016, 09:59 -0500, Vitaly Shukelanotifications@github.com, wrote:
|
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? |
@vi , yes, please. |
It's not that simple. Restored the function in a proper way: #2390 |
I remember wondering about whether the condition around adding |
Implement
cargo init
command and appropriate tests ( #21).Features:
cargo new
if there are no files in current directory--bin
[lib]
or[[bin]]
section toCargo.toml
in case of some non-standard source locationsConcerns: