Open enricosada opened 6 years ago
Personally, i dont like to do paket run hello
, i just want to have an hello
in PATH.
this make it easy to override commands, and you dont care about it after install.
cons:
/cc @Mpdreamz
Since the dotnet
cli is adding an extension point, I don't think we should pursue this.
Since the dotnet
cli is adding an extension point, I don't think we should pursue this part -
why? after restore fake (or paket run fake) with the avaiabile runtime (.net or .net core) fable (or paket run fable) who will work in any dir Similar: npm run
, yarn run , bundle exec (and binstubs), cargo
If someone needs to do all of that they should either extend their PATH
or write a build script.
But I'm all for enabling paket as a dotnet cli extension tool
info who can be useful later.
An example, dotnet cli is adding tools (sdk scooped) in v2.2 (ref https://github.com/dotnet/cli/issues/8067 )
the tools are just .net core fdd app published in the tools/netcoreapp2.1
dir of a nupkg.
ref a nuspec
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>global.tool.console.demo</id>
<version>1.0.4</version>
<description>test app</description>
<authors>testauthor</authors>
</metadata>
<files>
<file src="bin\Release\netcoreapp2.1\publish\*.*" target="tools\netcoreapp2.1\" />
<file src="DotnetToolsConfig.xml" target="tools\DotnetToolsConfig.xml" />
</files>
</package>
and an xmlfile to read the entry points, so commands can be renamed and multiple
<?xml version="1.0" encoding="utf-8" ?>
<DotNetCliTool>
<Commands>
<Command Name="demo" EntryPoint="consoledemo.dll" Runner="dotnet" />
</Commands>
</DotNetCliTool>
I saw this today and thought it might be relevant to the discussion: https://github.com/tonerdo/dotget
We need console app (tools from now on) for lots of reason in development.
Some are helpers for dev (dotnet-watch, serve, forge, ildasm).
Some are needed by build (nunit-console, ilrepack) or for both (fake, dotnet-fable, dotnet-xunit)
While the former (dev tools) MAY not need to be versioned with codebase, the latter (for build, for both) should be to make build reproducible.
Tools should be easy to install, nice developer UX from cli, easy runnable from shell scripts, multi os and runtimes, versioned with repo (if needed), can be invoked by any third party tooling.
paket should be able to manage per repo tool.
why? after restore
fake
(orpaket run fake
) with the avaiabile runtime (.net or .net core)fable
(orpaket run fable
) who will work in any dirSimilar:
npm run <cmd>
,yarn run <cmd>
,bundle exec <cmd>
(and binstubs),cargo <cmd>
An example of proposed is in https://github.com/enricosada/paket-repotool-testing/ ready to clone and use. it's the result of the WIP PR https://github.com/fsprojects/Paket/pull/2938 and will be maintained until is merged
We need two things:
For example. for an
hello
tool (who is just a .net console app)the binaries ( see also below), we can package in a nupkg, in
tools/netcoreapp/hello.dll
, andtools/net45/hello.exe
. Or just from github releasesFor invocation:
paket-files\paket\bin
directoryhello
/hello.cmd
who just rundotnet /path/to/tools/netcoreapp/hello.dll
ormono /path/to/tools/net45/hello.exe
paket run hello
(who just invoke that script file)adding in a dir the wrapper script, helps because is possibile to add it to
PATH
, and run commands just ashello
.More info https://github.com/enricosada/paket-repotool-testing/ README