Add --lib and status message for completion

[sophiajt]

This PR adds a --lib flag for creating a library with new/init. It also adds a status message for a successful completion.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[steveklabnik]

Hm, when we made cargo, we assumed the opposite. What's the basis here?

On Jul 26, 2016, 15:02 -0700, Rust highfive robot notifications@github.com, wrote:

r? @alexcrichton (https://github.com/alexcrichton)

(rust_highfive has picked a reviewer for you, use r? to override)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (#2921 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AABsioh44d3w_CYU7KUZbRZ6DMx5kkVJks5qZoPfgaJpZM4JVo20).

[steveklabnik]

Also, while Cargo is technically nightly, we've considered the CLI pretty
stable, this is a pretty big change in behavior.

On Tue, Jul 26, 2016 at 6:29 PM, Steve Klabnik steve@steveklabnik.com
wrote:

Hm, when we made cargo, we assumed the opposite. What's the basis here?

On Jul 26, 2016, 15:02 -0700, Rust highfive robot <
notifications@github.com>, wrote:

r? @alexcrichton https://github.com/alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2921 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABsioh44d3w_CYU7KUZbRZ6DMx5kkVJks5qZoPfgaJpZM4JVo20
.

[sophiajt]

@steveklabnik - Cargo is at "0.13.0-nightly (dc12479 2016-07-22)", so we're still pre-1.0. I agree that we don't want to go breaking things willy-nilly...

It looks like the hunch that most people would make libraries doesn't seem to play out from the results we're seeing. The 2016 survey puts "contributes to crates.io" as a minority of our users (roughly 550 of the 2000 active Rust users in the survey).

There's another intuition that if you're trying to make a library, you already have a bit of Rust experience under your belt. You know how to look up documentation and how to set up additional settings. I'd argue even into your first few days as a Rust developer you may not have created a library yet, but likely would have created a few small apps.

If the minority of users create libraries, and we're making users go down less ergonomic paths because of it, this seems like a good reason to change the default.

[alexcrichton]

One possibility for sequencing this as well is to add the --lib flag, wait for it to hit stable, then switch the defaults. (if we're worried about breakage).

I agree with @steveklabnik that despite cargo being "pre 1.0" it's basically defacto stable in many respects. I'm not too worried about breakage here, but it may be best to head it off by moving slowly.

I don't personally recall the exact reasons why we chose libraries as the default, but I'm sympathetic to the data just being the other way around so don't mind changing on that basis.

[alexcrichton]

Here we should just pass through flag_bin, right?

[alexcrichton]

Oh I see, yeah let's just pass through these flags as-is and have the "default logic" kick in during the implementation below

[alexcrichton]

cc @rust-lang/tools, thoughts about changing the default?

[nrc]

+1 on adding --lib, +0.5 on changing the default - It annoys me personally, I nearly always want --bin, but Cargo is de facto pretty stable, so we should do this gently rather than flicking the switch. In addition to Alex's suggestion, could we warn when doing cargo new with neither --bin nor --lib?

[brson]

I think I agree that --bin is a better default purely for the new user experience, regardless of what people do most often, and also that switching it without warning would be undesirable. I also know that I just never remember which is the default and am sometimes surprised that I have a library after creating a cargo project (particularly for the numerous one-off experiments that just get thrown away).

I'm unsure the best way to proceed, or if the breakage is worth it.

Another way we could transition is by temporarily changing cargo new to produce a crate that makes both a lib and a bin and in the lib.rs source write a comment explaining what's going on.

[sophiajt]

So it sounds like we're leaning towards making it the default but with caution.

Maybe we can switch the default but also just add a general result message for any new/init? Something like:

> cargo new foobar
  Created binary (application) `foobar` template

[alexcrichton]

@nrc

could we warn when doing cargo new with neither --bin nor --lib?

I think the motivation for this PR from @jonathandturner was to simplify the newbie experience with just cargo new foo being much simpler than cargo new foo --bin in terms of aesthetics.

Another way we could transition is by temporarily changing cargo new to produce a crate that makes both a lib and a bin and in the lib.rs source write a comment explaining what's going on.

This... seems like a great idea! @jonathandturner what do you think of this?

The idea of a status message also seems fine to me, it's arguably just missing today.

[sophiajt]

I lean towards the status message.

Putting both in works on one level, since it doesn't have a preference. But what I'm trying to fix is that there's a happy path for users, especially new users. If a new user types "cargo new foo", they'll end up getting more than they have today that they need to read and understand. I'd rather have a simple starter template.

[wycats]

I'm comfortable with adding --lib now and printing a warning (for now) when people use bare cargo new (similar to the warnings about git changing the behavior of git push). After some time, we can change the behavior to default to --bin and remove the warning.

[sophiajt]

Switched to using @wycats/@nrc's suggestion, so I now warn if you do a cargo new without a target.

Default is back to --lib.

I also added a status message for successful completion of a new/init.

[sophiajt]

Started a thread here: https://internals.rust-lang.org/t/should-cargo-new-default-to-applications/3772 to see if we should change the default. For the time being, leaving the PR as a simple "add --lib and add a status message".

[alexcrichton]

Can this be pushed into ops to deduplicate betwen here and new? (same with the if block above

[sophiajt]

The messages are different between init and new, so I'm not sure how much that would buy us.

[alexcrichton]

Oh ok, in that case maybe it could be pushed down into the init and new functions? (would be good to deduplicate the if above in any case)

[sophiajt]

@alexcrichton Fixed and squished. Defaulting now happens in a constructor that's shared by both functions.

[alexcrichton]

Ah right one last thing is could you add a test where both --lib and --bin are passed? Other than that lgtm

[sophiajt]

@alexcrichton - done.

[alexcrichton]

@bors: r+ a0a7752

[bors]

⌛ Testing commit a0a7752 with merge f1bbc08...

[bors]

☀️ Test successful - cargo-cross-linux, 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
Approved by: alexcrichton
Pushing f1bbc08 to master...

[SoniEx2]

Why can't specify both bin and lib? You /can/ have both lib.rs and main.rs... (Should I be opening a new issue instead of hijacking a merged PR?)

[alexcrichton]

@SoniEx2 ah yeah in general you should be able to combine any number of --bin, --example, --lib, etc flags. Right now the option parser doesn't quite handle all the cases but it's indeed an issue that should be tracked on this repo most likely