`cargo new` should allow me to set the default package version

[dradetsky]

Problem

Currently, if I run cargo new mypkg it creates Cargo.toml with version set to 0.1.0. This appears to be because we hardcode this version in https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_new.rs#L801. I would like to be able to configure cargo to use a different default version.

Proposed Solution

Add a field to the cargo configuration file

[cargo-new]
version = '1.0.0'

If present, cargo new mypkg would be created with the version set to 1.0.0. Otherwise, we would default to creating packages at 0.1.0.

Notes

Hopefully, we can just ignore questions like "Should we allow the user to set the initial version with a flag? Or an env var?" My feeling is: set-by-config is the only thing I want in terms of an actuall feature I want to use, as opposed to something to be added for completeness/consistency. If for some reason I really need to programmatically create packages with a specified version, I can hack something together with project-local config files.

[epage]

For me the question is about the use case. Why do you want to change the default? To what?

Note: generally, we've been pushing back on configuration in favor of some nebulous future templating system.

[dradetsky]

@epage In this case, I want to set the default init version to 1.0.0 specifically because I want to ignore all of the "x > 0" stuff from semver (since it's too late to convince the semver people to not have 0.y.z be a special case). I want to set this as a default value because editing the manifest every time makes me feel silly.

Note: generally, we've been pushing back on configuration in favor of some nebulous future templating system.

I mean, how many potential configurations are you pushing back on?

Like a package template system can be fantastically (over)complicated. As a user, my first step was to check https://doc.rust-lang.org/cargo/reference/config.html. Then upon seeing that the only option for new was vcs, I became annoyed and started to look into adding a new config option. The way I would like it to work was to just see version in that list and set it.

By contrast, the package template system for something like C# is a real pain to learn to work with. The amount of effort I put in just to get it to spray less boilerplate into my projects was quite annoying. The system for Clojure was somewhat less annoying, but still way more than I would like to deal with for something this simple. It feels like a way bigger hammer than you need.

Now if all this extra stuff to learn as a user was paid for by simplicity of implementation for the core team, I'd get it. But I imagine it's more effort. It seems like you need a lot of different initial project shapes before it's worth the extra complexity. Instead, you could just expose all the relevant options as configs, and that's just:

• version
• edition
• publish

Which isn't that much.

[dradetsky]

More: If it was up to me, I would want to keep new/init very simple the way they are now. Then for more complicated use-cases have another command like cargo template myorg-std-exe foobar to create a new package called foobar from the template myorg-std-exe. Intentionally, the manifest created by new would be kept very simple as it is now, and thus the amount of configuration even theoretically available via a config file would be kept small.

As a result, for most users who just want to do something simple like "I want new project packages to always use edition X (unless I explicitly pass something else on the CLI)", said users do not need to learn how the package template system works to solve their problem. But when people start wanting to do stuff with workspaces, you say "That's out-of-scope for new, use template and read the roll-your-own-template chapter."

[epage]

#5151 is the template issue and you can look through the backlinks to see what all customization people want.

Each person wants things a little different and each feels their case is justifiable on its own.

Let's also take on example, edition: how many people needing this also are in a workspace? If so, cargo new will inherit the workspace's field

[dradetsky]

So I can understand how you would view my request as "one more of these things" and thus not be too enthusiastic about it. However, in my opinion, it is distinguishable from most of them. The real reason why you should not care or want to reject my proposal is that it's not very important, not that it's the same kind of thing.

Most of the customizations which people have requested in the past were one of:

1. Requests to implement templates
2. Requests for additional files to be created by cargo new.
3. Requests having to do with workspaces, which I don't currently understand or use.

Obviously (1) is out of scope for direct implementation into new, because it is solved by the hypothetical future template project.

(2) represents things trivially implementable via the template system. There's nothing easier that putting a boilerplate .gitignore in your template.

(3) represents things where I can't easily say if they're the same kind of thing as my proposal or not, so I won't.

By contrast, my assumption is that there's no reason why the default functionality for cargo new needs to change ever, even if templates are added. Sure you could add templates for users with more interesting requests, but the existing very-basic implementation seems fine. If so, then making it configurable is different from adding a README.

Let's also take on example, edition: how many people needing this also are in a workspace? If so, cargo new will inherit the workspace's field

As I implied, I don't use workspaces. I wanted this for non-workspace applications.

[dradetsky]

I've actually halfway talked myself out of this, so maybe it should just be rejected if nobody is interested.

[weihanglo]

I want to set the default init version to 1.0.0 specifically because I want to ignore all of the "x > 0" stuff from semver (since it's too late to convince the semver people to not have 0.y.z be a special case). I want to set this as a default value because editing the manifest every time makes me feel silly.

Out of curiosity. Is this an effort of changing the culture, or are you often creating new packages? If the latter, how under what kind of workflow/circumstance you need to create new packages frequently? To me at work, I found it actually uncommon for a single developer to create new packages. And often for large teams for organizational purpose, they need more than version/edition but also package name convention, lints, dependencies, and that usually evolves to a template system. It it unclear to me about those use cases that don't want templates but one-off flags.

[dradetsky]

Out of curiosity. Is this an effort of changing the culture, or are you often creating new packages?

Although I'm new to Rust, in the past I have in fact often created lots of packages with cargo new equivalents in other languages. So I anticipate doing so in Rust too if I keep working with it.

I don't specifically intend to change the broader programming culture, but I've often wanted to implement specific standards in my own companies or teams. If I'm going to do that, I want to be able to tell my colleages/subordinates "Just set this option in your config; in fact, here's the official recommended config for you to use/modify" rather than "Make sure to always make the following change." The latter will feel annoying to people who don't really understand the value of the standard and/or how it fits into other standards and practices of the organization, and people typically prefer to get on with their own work than to fully understand your ideas, etc. But if you tell them to just do a bit of setup once, and it makes a change which to them seems unimportant, they tend to think it's fine.

often for large teams for organizational purpose...that usually evolves to a template system.

Yes, but no template system exists currently. This is about a feature that I would like given that there is no template system, and is arguably worth retaining after a template system is implemented.

If the latter, how under what kind of workflow/circumstance you need to create new packages frequently?

One example is when I'm experimenting with how to structure a solution to a problem, so I end up creating one package, doing a little work on it, then thinking "No, I should use approach B" so I make another package, work on it a bit, consider another approach, go back to a previous approach, etc. These might not be standalone packages, but libraries to integrate into an existing project, so semver considerations are somewhat relevant. Admittedly, for this particular case, I do this more often on personal projects than in organizations, so the organizational considerations I mentioned above don't apply.