Feature Request: command that runs ConfigureDotNetForFirstTimeUse

[vcsjones]

Steps to reproduce

When building our own custom images that have .NET Core on them, we would like to prime the nuget cache while the OS image is being built. Currently, we do this by having a dummy project.json in a temp directory, then calling dotnet restore on it. That way when OS images are spun up, they don't lose ~10-20 seconds.

This feels a little "duct-tapish" to me. It would be very handy if there were a specific CLI command that did only this "priming" of the nuget cache.

Expected behavior

A command, such as --prepare, that runs ConfigureDotNetForFirstTimeUse. It should be a no-op if the cache is already there. It should also return an exit code of zero so that build scripts / Docker files don't think the image creation failed.

Actual behavior

There is no command.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview2-003148)

Product Information:
Version: 1.0.0-preview2-003148
Commit SHA-1 hash: 18ca244551

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.12
OS Platform: Darwin
RID: osx.10.11-x64

[TheRealPiotrP]

@blackdwarf what do you think? I've heard this come up a few times.

dotnet ensure-first-run-experience?
dotnet --ensure-first-run?

I don't love either name, but we do need to provide this functionality...

@livarcocc

[blackdwarf]

@piotrpMSFT I've already talked with @MichaelSimons about this a while back. My suggestion was that given that this was a configuration task that we expose this through a more general-purpose configure verb in the CLI.

I would like to avoid adding a lot of top-level switches for various things and would rather we have top level verbs that can/should contain multiple similar functionalities.

[vcsjones]

I'm happy to take a stab at a PR for whatever we decide is the correct thing to do.

[TheRealPiotrP]

configure implies that we're going to be changing configuration. This really just unpacks nuget packages. I'd prefer to reserve configure for repeatable actions and give this its own verb.

dotnet first-run?

[livarcocc]

if you invoke that command and you had the SKIP_FIRST_RUN env variable set, should we still do the first run? Should we silent skip? Give a warning and return a non-zero error code?

@blackdwarf can you pick a verb and define the behavior given my question above? Once that's done, @vcsjones it would be great to get a PR from you.

[vcsjones]

@livarcocc

if you invoke that command and you had the SKIP_FIRST_RUN env variable set, should we still do the first run?

My opinion is that I think it should skip anyway, and not error-out. It seems like the environment variable should always take precedence. Since it's external, that is something might be setting it without being aware that this new command is even being used, I would think the environment variable should "win".

Example: you have a docker image with .NET Core on it that does a build. DevOps has no idea what the container does inside, but they know they don't want .NET Core's installer to do the first run behavior. No problem, they can put ENV SKIP_FIRST_RUN 1 in their Dockerfile. I would have been surprised if it ran it anyway, even if it were done explicitly.

[blackdwarf]

As a point, I really, really dislike the idea of this being a top level switch/command.

Also @piotrpMSFT my idea was to introduce configure as a top-level verb and have this be one of the many things you can configure using that verb in the CLI.

Thoughts?

[vcsjones]

@blackdwarf

I tend to agree. Perhaps something like dotnet configure --for-first-run. That probably runs afoul with all of the naming guidelines, but I like the expressiveness of being able to read it as a sentence. An alternative would be dotnet configure --first-run.

[MichaelSimons]

As @blackdwarf referenced earlier we had discussed this in the past and I had already logged an issue for it - https://github.com/dotnet/cli/issues/3692

[TheRealPiotrP]

@vcsjones once @blackdwarf locks the design, are you interested in making a PR?

[vcsjones]

@piotrpMSFT yes. I already took a look at what it would take to accomplish this and I don't see any major difficulties.

[TheRealPiotrP]

@blackdwarf assigning over to you for driving design. Let's try to get a spec out early next week?

[FLGMwt]

Hi there! Was snooping around after my incredibly ambitious dotnet/cli#5507 (; D) and thought this sounded interesting.

It looks like the current call to ConfigureDotNetForFirstTimeUse happens before the command is delegated to the verbs. Meaning it would get called before dotnet-configure had anything to do about it.

Am I crazy or would a noop configure --first-run do the job here? Assuming dotnet-configure is built out properly to not make it a burden for the next dotnet configure flag.

If implementing this with a noop seems janky, what should the approach be?

[FLGMwt]

Also, don't know if this helps, but I just downloaded rc4-004706 and typo'd a dotnet nhelp. Since that didn't catch any of the guards in src\dotnet\Program.cs, it ran the first time configure and only after the 10-20s setup did it output No executable found matching command "dotnet-nhelp".

I suppose filtering out that exit code is trivially cheaper than a throwaway project :p

[TheRealPiotrP]

@FLGMwt FYI the new dotnet new doesn't drop any files by default, showing a menu instead. And it returns 0 :)

[old-scalefocus]

Hey guys, what about just dotnet init?

[andres-k]

dotnet init also implies setting some sort of values or creating something in my opinion. Maybe attach it to dotnet restore, dotnet restore --only-cache ? Would conflict with the basic usage of dotnet restore but seeing it as kind of a niche option, I think it would be fine.

[old-scalefocus]

dotnet init is making analogy with the distributed source control system (Git, Mercurial).
If we consider dotnet core is a distributed framework now, why not using same sort of commands to create a local copy of it?
Following the analogy other possible could be:
dotnet clone
dotnet pull

[wli3]

In 3.0, there is no nuget prime anymore.