Distribute as global package

[dazinator]

Hi, this looks fantastic.

Please consider publishing warp as:

• chocolatey package
• npm package
• dotnet cli global tool

That way, it will be easier for some folks to obtain the tool and keep track of updates when you issue new versions. It will also automatically be put on the PATH if desired by the user!

[RichiCoder1]

Considering the target for this, a dotnet cli global tool makes a ton of sense.

[phrohdoh]

Some, hopefully helpful, resources:

https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools-how-to-create https://github.com/NuGet/Home/issues/6645

[dgiagio]

Sounds like a good idea to have a dotnet CLI global tool. It could probably be just a simple wrapper on top of the existing warp-packer tool as it's portable enough.

[Calinou]

Just a heads up, warp was added to Scoop: https://github.com/lukesampson/scoop/pull/2669 :smiley:

[Hubert-Rybak]

I created .NET CLI global tool, which is a wrapper around Warp and ILLink.Tasks for optional assembly stripping before packing, maybe someone would be interested: https://www.nuget.org/packages/dotnet-warp/

[CoolOppo]

I disagree with the dotnet core global tool idea. You could easily just distribute this using cargo. Dotnet global tools require you to have dotnet core installed to use them anyways, and it's just another step every time you want to release a new build of warp. If you use cargo, everyone can install it on all platforms with cargo install and it's the tool designed to be used for this specific purpose a lot of the time (rust program binaries). I would much rather prefer taking that route as opposed to having one package on tons of different package managers that are all out of sync.

Edit: another thing with dotnet global tools is that they are SLOW... It takes far longer to invoke them for some reason. Maybe that's only for tools that are actual CLR exes and not native exes though, so I could be wrong.