Feature Request: command that runs ConfigureDotNetForFirstTimeUse #4919

Open
vcsjones opened this Issue Dec 5, 2016 · 16 comments

Projects

Ready in Dotnet CLI Preview 5

8 participants

@vcsjones
Contributor
vcsjones commented Dec 5, 2016 edited

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: 18ca244

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

@vcsjones vcsjones added a commit to vcsjones/AuthenticodeLint.Core that referenced this issue Dec 5, 2016
@vcsjones vcsjones Prime the nuget cache.
There isn't a good way to "prime" the nuget cache without side-effects
in the .NET CLI. So we create a new project in a scratch directory and move it.
Opened dotnet/cli#4919 as a suggestion.
03980fd
@piotrpMSFT piotrpMSFT added this to the 1.0.0-rtm milestone Dec 5, 2016
@piotrpMSFT
Collaborator

@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
Contributor
blackdwarf commented Dec 5, 2016 edited

@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
Contributor
vcsjones commented Dec 5, 2016

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

@piotrpMSFT
Collaborator

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
Member

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
Contributor
vcsjones commented Dec 6, 2016

@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
Contributor
blackdwarf commented Dec 6, 2016 edited

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
Contributor
vcsjones commented Dec 6, 2016

@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.

@piotrpMSFT piotrpMSFT modified the milestone: 1.0.0-preview5, 1.0.0-rtm Dec 13, 2016
@MichaelSimons
Contributor

As @blackdwarf referenced earlier we had discussed this in the past and I had already logged an issue for it - #3692

@piotrpMSFT
Collaborator

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

@vcsjones
Contributor

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

@piotrpMSFT piotrpMSFT assigned blackdwarf and unassigned jonsequitur Dec 18, 2016
@piotrpMSFT
Collaborator

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

@piotrpMSFT piotrpMSFT modified the milestone: 1.0.0-preview5, 1.0.0-rtm Jan 18, 2017
@blackdwarf blackdwarf modified the milestone: 2.0.0, 1.0.0-rtm Jan 19, 2017
@FLGMwt
Contributor
FLGMwt commented Jan 29, 2017

Hi there! Was snooping around after my incredibly ambitious #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
Contributor
FLGMwt commented Jan 29, 2017 edited

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

@piotrpMSFT
Collaborator

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

@derwasp derwasp referenced this issue in derwasp/jenkins-jnlp Feb 28, 2017
Open

Pre-initialize .NET Core #2

@scalefocus

Hey guys, what about just dotnet init?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment