Sdk: Implicit restore for cli tools

[forki]

dotnet build now has implicit restore and it's considered a good thing.

Unfortunately we don't have it for cli tools.

Consider commands like: dotnet fable webpack-dev-server (see https://github.com/SAFE-Stack/SAFE-BookStore/blob/master/build.fsx#L212)

They just fail with something along the lines "Can't find command "dotnet-fable" not found"

It would make things so much easier if cli would restore in that case and rerun.

Environment data

dotnet --info output : 2.0.0

[alfonsogarciacaro]

As devs are not still used to dotnet SDK CLI tools, it often happens that when they see the error message they think they need to install Fable (or any other cli tool) globally. So if dotnet SDK could detect if a restore is needed before giving up executing a command, that would prevent a lot of confusion.

It'd be also very nice if the CLI tools could be run in the solution and not the project directory, but that's another topic ;)

[cartermp]

Definitely 👍 this. Now with implicit restore in the SDK, I often forget to invoke restore for these tools (and I suspect others do too). Getting implicit restore for CLI tools makes using Fable and the ASP.NET tools really low friction.

[livarcocc]

@emgarten any concerns?

[emgarten]

I'm all in favor of implicit tool restore. Originally I think NuGet asked for this so that the CLI could pass the correct tool framework at runtime which would remove the guess work for restore. We didn't go that route, I can't recall why but some of the problems I see are with timing. The name of the command(s) available are not known until after the package has been restored.

Example for an unknown command with implicit restore:

1. dotnet builf (typo)
2. if tool references exist then dotnet needs to check if dotnet-builf exists in a package. (The package name does not indicate the commands which may be available).
3. restore all tool packages
4. discover that the command does not exist
5. fail with an unknown command message after potentially a long restore on a slow connection

I don't know all the details on how tools are resolved, so I might be wrong on this or there could be a way around it.

[cartermp]

I think that (3) is the right behavior; that is, I expect that people would want all tools restored if they have them specified in their project files.

Then, if the command still doesn't exist, could we probe for commands which do exist and list them in the error message?

$ dotnet fabuhl

No executable found matching command "dotnet-fable".  The following tools are available:

    dotnet-fable
    dotnet-watch

Did you mean one of these?
$

I'd assume that any error due to a long restore on a slow connection wouldn't be different than for any other package, right?

[emgarten]

Listing available commands is a good idea. I agree that it isn't worse than a normal slow restore, the point I was trying to make is that it adds network calls to a scenario that did not have them before.

[forki]

Yes ordered by edit distance. This would make a huge usability win.

Am 28.09.2017 00:23 schrieb "Justin Emgarten" [e-mail]:

Listing available commands is a good idea. I agree that it isn't worse
than a normal slow restore, the point I was trying to make is that it adds
network calls to a scenario that did not have them before.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/7715#issuecomment-332672915, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADgNNVO66PzBzxf_Fabb9mchRwn1Jkjks5smsr3gaJpZM4PlwAi
.

[alfonsogarciacaro]

@emgarten has a good point, but this would only happen if the user both forget to restore and do a typo, right? At that point may be they deserve some network latency ;)

At a minimum the error message should be completed like: No executable found matching command "dotnet-fable". Please restore the project and try again., but the ideal solution is the one proposed by Phillip so :+1:

[forki]

I don't think "dotnet build" vs, "dotnet builf" is a real issue.

let's look at the cases:

1) not restored yet + "dotnet build" => restore is implicitly run, user waits, stuff builds
2) already restored + "dotnet build" => stuff builds
3) already restored + "dotnet builf" => cli shows error directly
4) not restored yet + "dotnet builf" => restore is implicitly run, user waits, stuff doesn't build

so as we can see in no case it's actually slower.

[forki]

ping. any plans to implement this? It would be extremely useful for fable and safe stack apps and probably also for the rest of the ecosystem

[livarcocc]

It is currently placed in our 2.1.4xx milestone, though for us to see how feasible that is. I am not sure this will make into the release.

[forki]

Did someone already started to work on this?

[livarcocc]

Given the shift to global tools (and soon local tools) and the fact that we are recommending that people move in that direction, we are not going to take this improvement.

[forki]

Uhh can we please discuss this again? Global tools are unrelated to this.

[livarcocc]

We have decided to not continue investing on project tools and just maintain it for backwards compatibility. It has been discussed in a few different issues on this repo before.

We did that because we believe the global tools model (with local tools) is the future we want to drive for the tools ecosystem on dotnet.

[forki]

Ouch. That hurts. I mean repo tools are badly needed, but what if I need different fable compiler versions for different projects? It's definitely going to introduce a lot new challenges.

[alfonsogarciacaro]

Thanks for the information @livarcocc. Any pointer where we can see the results of these discussions for the future of dotnet tools? They've changed quite a bit in latest SDK releases and the MSFT documentation only includes information for users, not authors. I could only find this blog post but still have questions (e.g. is the prefercliruntime file still needed?).

Global tools are convenient but local tools also have two great advantages:

• It's one less global requirement when installing a template/cloning a repo. This makes it much easier to try out things.
• Most importantly as @forki says, it allows specifying the tool version in each project. This is crucial to have reproducible builds. Is there any plan to enable version control of global tools per directory as with global.json for the SDK?

[livarcocc]

@KathleenDollard for documentation and write ups. And just to be clear, we will maintain project tools support, however, we don't have plans to continue to improve it, as we believe their utility will be reduce and most people will use global/local tools.

[KathleenDollard]

@forki and @alfonsogarciacaro you said "specifying the tool version in each project". Did you mean (more or less) each repo or solution?

Local/repo tools (we'll call them local tools in the future) will be relative to where you are running the command. For builds, this should be straightforward and will follow how we find other files. We anticipate this solving both the problem of different versions for different repos, and making it easy to clone, tool restore, do work.

Local tools will be like global tools in that they are just console applications - and thus they run in their own process space and their own version of the .NET Core Runtime. The addition for local tools is how they are declared and stored. Thus, no more prefercliruntime!!

I'm sorry we are behind on docs - both for global tools and our local tool design. A simple version of creating a global tool should go into docs quite soon. That article is not intended to cover all the side cases, so we still need to write that article.

There's a bit more information about our local tool direction here: https://github.com/dotnet/cli/issues/9782#issuecomment-410033494
https://github.com/dotnet/cli/issues/9782#issuecomment-410033494

[alfonsogarciacaro]

Thanks a lot for the information and the link @KathleenDollard! I didn't understand very well when @livarcocc talked about local tools but I'm very glad to see you're planning to cover the repo-wise scenario (actually I do prefer tools being repo-wise rather than project-wise). Is there a place where, as a tool author, we can follow the progress of this and give our opinion? At the moment my wish list would be:

• Being able to pin the version repo-wise (I see you're already on it). I guess @forki would love if this can be managed from a 3rd tool like Paket, but at a minimum I'd prefer not needing another extra file for this (global.json can be a good option indeed).
• The tool would be installed automatically when restoring if not present in the machine.

[forki]

While I'm really looking forward for repository wide tools since day 1 (I'm
original author of FAKE and Paket which always have been repository wide
tools) I really think it's unfortunate to call these "local". In my opinion
project tools continue to be super important, especially in times when we
upgrade compilers in larger solutions.
Let's assume fable 2 was released an I want to upgrade. Now I may want to
do this project by project and not in one big bang.

I hope you folks reconsider and continue to work on both "local" versions.

Alfonso Garcia-Caro [e-mail] schrieb am Mi., 29. Aug.
2018, 23:12:

Thanks a lot for the information and the link @KathleenDollard
https://github.com/KathleenDollard! I didn't understand very well when
@livarcocc https://github.com/livarcocc talked about local tools but
I'm very glad to see you're planning to cover the repo-wise scenario
(actually I do prefer tools being repo-wise rather than project-wise). Is
there a place where, as a tool author http://fable.io/, we can follow
the progress of this and give our opinion? At the moment my wish list would
be:

• Being able to pin the version repo-wise (I see you're already on
  it). I guess @forki https://github.com/forki would love if this can
  be managed from a 3rd tool like Paket, but at a minimum I'd prefer not
  needing another extra file for this (global.json can be a good option
  indeed).
• The tool would be installed automatically when restoring if not
  present in the machine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/cli/issues/7715#issuecomment-417107661, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADgNNSWRAO9kXRG73Dl4LfKrS1kp2Mwks5uVwPRgaJpZM4PlwAi
.