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

Cargo new in empty dir #2008

Closed
wants to merge 3 commits into from
Closed

Conversation

vi
Copy link
Contributor

@vi vi commented Sep 29, 2015

  • Implement cargo new .. It checks if directory is empty (or contains only VCS-related files)
  • Make cargo init suggest new . instead of just new

vi added 3 commits September 29, 2015 16:54
Allows "new" command even if path exists,
if the path is empty or almost empty directory.

Also more narrow duplicates: rust-lang#1990, rust-lang#1065, rust-lang#526.
The test was testing that "cargo new" fails when the directory
already exists.

Now it also creates a file in this directory.

There should be more tests for this, this is a quick fix.
@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 @huonw (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.

@@ -45,9 +45,41 @@ struct CargoNewConfig {
version_control: Option<VersionControl>,
}

fn can_we_use_this_path_for_a_new_project (path: &Path) -> bool {
Copy link
Member

Choose a reason for hiding this comment

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

love this fn name

@steveklabnik
Copy link
Member

🎊 i am excited to have this

@vi
Copy link
Contributor Author

vi commented Sep 29, 2015

I don't understand the failure from Travis-CI.

@alexcrichton alexcrichton assigned alexcrichton and unassigned huonw Sep 30, 2015
@alexcrichton
Copy link
Member

Thanks for the PR @vi! The intention right now is to have cargo new and cargo init be distinct commands where the former is "create new files/directories" and the latter is "probe an existing structure to generate Cargo.toml". In that sense I don't think that we want to special-case the "." argument to cargo new, but instead leave this sort of logic to a new init command.

The init command is unfortunately more involved, however, so it may be more difficult to add!

@vi
Copy link
Contributor Author

vi commented Sep 30, 2015

@alexcrichton,
It's not . special-cased, it's just the destination must not exist got appended by or be empty-ish directory.

The only explicit . is in reaction to non-existing cargo init command, in the help message.

Is implementing a preliminary "init" command without too involved logic (i.e. not trying to do VCS things) a good idea? Just to stop annoyance and pump down tension.

@alexcrichton
Copy link
Member

Although this is just "new in a directory with only VCS files" I feel that it's similar enough to cargo init to warrant the new subcommand. I think the only real "hard" part about cargo init is that it'd want to be very careful to not overwrite any existing files and also put effort into probing the filesystem with normal conventions to create a Cargo.toml. So in that sense it may not be too hard to do, but I also would rather have a full-fledged cargo init (or at least most of the way there) rather than just cargo init . in a directory with only VCS files.

@vi
Copy link
Contributor Author

vi commented Oct 1, 2015

@alexcrichton, What are requirements for a "fully feldged cargo init"? Can I can just try going and implementing it or it needs a discussion/RFC?

@alexcrichton
Copy link
Member

I think it'd be fine to implement without an RFC, and discussion can probably happen on the PR as well. I'd expect pieces along the lines of:

  • No files are overwritten without consent
  • A Cargo.toml is generated after probing for files like lib.rs, src/lib.rs, etc, generating appropriate targets with appropriate names and such.
  • Perhaps some flags (e.g. --lib PATH or --bin PATH) to customize the functionality.

It doesn't have to be too too complete to start off I think (it'll have room to grow).

@vi
Copy link
Contributor Author

vi commented Oct 3, 2015

Is the following for initial implementation of caro init OK?:

  1. If current directory is empty, behave like in cargo new;
  2. If current directory contains .git subdirectory, behave like in cargo new --vcs git, except of don't create Git repository again;
  3. If current directory contains .hg subdirectoiry, behave like in cago new --vcs hg, except of don't create Mercurial repository again;
  4. Otherwise, fail.

@alexcrichton
Copy link
Member

I would personally prefer a more feature-ful implementation along the lines of "I just created this structure but forgot cargo newwould do it for me" where there's perhaps a lib.rs or src/lib.rs lying around but just a missing Cargo.toml that needs to be generated.

@vi
Copy link
Contributor Author

vi commented Oct 5, 2015

@alexcrichton, Do you approve this algorithm for cargo init?:

part1

part2

@alexcrichton
Copy link
Member

Yeah that looks pretty good to me! I'd probably avoid actually moving files and instead just generate a Cargo.toml that points to the right place, but looking good!

@vi vi mentioned this pull request Oct 26, 2015
@alexcrichton
Copy link
Member

Closing in favor of #2081

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))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants