Added dotnet tool support #12

martinbu · 2023-08-30T08:36:34Z

Hi,

I want to ask what do you think about adding support for using the nuget also as dotnet tool. So running it with dotnet tool run as described here.

I have added a basic initial implementation (which you can see in the PR) that works fine for me. The question is, can we get rid of the Gettext.Tools.nuspec file because for the dotnet tool to work, a project file must be used where the nuget information must/can be added. At the moment the information is just duplicated and the project must be packed with dotnet pack

Afterwards, the tools nuget can for instance be used like:

dotnet tool run Gettext.Tools -- msgcat --output-file="%mergedFile%" "%tmpDir%/"*.pot

What do you think about it? Are you able to integrate that in a clean way? Or do you have suggestions how I can integrate it in a more clean way?

vslavik · 2023-09-01T17:02:59Z

What do you think about it? Are you able to integrate that in a clean way? Or do you have suggestions how I can integrate it in a more clean way?

I'm open to it and happy to merge a good PR (one commit per one thing, well-described) if it makes sense and there's a benefit to it.

I don't mind changing the way the package is built, if the end result is the same (or at least the same for practical purposes) and you do the work of updating the actions.

I do not however understand why would this be desirable in the first place (the link you provided doesn't really explain it) instead of simply calling the tools directly from the package. So understanding that is a prerequisite.

vslavik · 2023-09-01T17:03:44Z

src/.gitignore

@@ -0,0 +1,398 @@
+## Ignore Visual Studio temporary files, build results, and


These changes are both unrelated to the commit message and pointless - don't use generated ignore files that don't apply to the project in question!

I have moved the needed ignore path to the root gitignore file

vslavik · 2023-09-01T17:05:31Z

src/Gettext.Tools/Program.cs

+            Console.WriteLine("Usage:");
+            Console.WriteLine("  Gettext.Tools -- <TOOL_NAME> [tool specific options]");
+            Console.WriteLine();


I don't really understand how to use it from this help. It would be good to add some documentation to the readme file too...

I have added more information to the usage output and additionally added a readme.md file for the dotnet tool nuget package.

martinbu · 2023-09-04T06:44:37Z

I do not had the intention that this PR is merged "As-Is". I just want to discuss how, if it makes sense and whether you are even want to add support for dotnet tool in advance before putting effort into this. Admittedly, this was not clearly written.

The link I provided is the documentation for how a dotnet tool nuget package can be setup, built and run. A good article about what a dotnet tool is and why to use dotnet tools can be found e.g. here.

My use case is the following: I have a project from which I extract the translateable string with the PoExtractor - which is also a dotnet tool - and afterwards merge / filter / ... the extracted pot/po files with the gettext tools. All of this can be done with a dotnet-tools.json file which describes the tools needed and a batch script that ensures that the dependencies are installed (dotnet tool restore) and then doing its work.
Of course, the described process could also be integrated in a dedicated build process but with additionally providing the package as a dotnet tool you simple have more application possibilities.

Why not calling the tools directly from the package?
I am not an expert into nuget packages - so correct me if I am wrong. But in this case the nuget package has to be installed and afterwards be used in the correct context (environment must be setup to find the tools). This is not an issue in a build process. But if you want to use the tools from command line, maybe not even in the context of a .NET project, they are much simpler to use if they are installed as a dotnet tool. A dotnet tool can only define one ToolCommandName which in my proposal is just the forwarder to the tool that a user wants to execute.

This is a preparation for adding dotnet tool support for this nuget package. All metadata is moved from the Gettext.Tools.nuspec to the Directory.Build.props file which gets applied to all projects on a lower directory level. A new project src/Gettext.Tools was introduced which contains the package id and additional files that are only needed for the nuget PackageType "reference". Additionally, the project is used to build the nuget package with the "dotnet pack" command which is now used by the Makefile. The resulting package is exactly the same as if it was created with the nuspec file.

With these changes, the Gettext.Tools can additionally be installed as a dotnet tool. This makes it possible to install it as global tool and directly use it from the command line. A dotnet tool can register only a single command. Therefore, the gettext tool itself must be passed as a parameter, including individual options, to the "top-level" Gettext.Tools command. e.g. Gettext.Tools -- <TOOL_NAME> [tool specific options] It was needed to create a separate nuget package for the tools functionality as the PackAsTool property removes all other package types from the generated nuspec file.

martinbu · 2023-09-04T14:34:12Z

I have cleaned up the PR now. It seems not to be possible to create a nuget package with both DotNetTool and default Reference package type when using the PackAsTool property. As soon as I have added the PackAsTool property, all other package types get removed from the generated nuspec file.

As a consequence, I have added a separate nuget package configuration for now. The addtional nuget package is build by the Makefile target nuget. But I did not have added it to the publish target yet.

To check if the original package did not have changed by the new tooling, I have extracted the new package content on the original one (which I have tracked with git). These are the only differences:

vslavik · 2023-10-05T16:29:29Z

The GitHub Actions build is failing due to missing dotnet executable.

I am confused by this:

It seems not to be possible to create a nuget package with both DotNetTool and default Reference package type when using the PackAsTool property. As soon as I have added the PackAsTool property, all other package types get removed from the generated nuspec file.
As a consequence, I have added a separate nuget package configuration for now. The addtional nuget package is build by the Makefile target nuget. But I did not have added it to the publish target yet.

You say the package didn't change, but you also say it is of some different kind now? And that there will need to be two published packaged, or do you mean something else?

I'm OK with merging this, but it's unclear to me if my requirement that the new packages will be drop-in replacement for the old ones, i.e. backward compatible, is met?

martinbu · 2023-10-09T07:18:27Z

The current package did not change, it can be a drop-in replacement for the current package. This is because I have not changed anything except that the package is built with dotnet pack instead of nuget pack now and that all the "Package Meta Information" is moved from Gettext.Tools.nuspec to Directory.Build.props (which is needed by dotnet pack)
All of this is done in the first commit: Migrated from nuspec to sdk style nuget package.
To ensure that the package did not change I have compared the content of the original and the newly build package as shown in the screenshot above. This was important to me because I do not want to break any existing functionality. And because I did not know all the use-cases of using the original package at the moment this was a good and sufficient check for me.

This was the preparation for adding dotnet tool support in a second step. According to the documentation multiple package types can be set for one nuget package. Therefore, my intention was to just add the additional Package Type DotnetTool to the original nuget package. But as my tests have shown it is not possible to set both, Dependency and DotnetTool for one nuget package - although I could not find anything about that restriction in the Microsoft documentation.

As a consequence, I have not changed the "original" nuget package (except moving from nuget pack to dotnet pack), but have added a second nuget package which reuses all the nuget package meta information and of course the gettext-tools binaries and pack that as nuget package with PackageType DotnetTool. In my opinion this could/should be released in parallel with the original nuget package because it has in fact the same content as the original package only with a different use case, namely using it as dotnet tool.

The GitHub Actions build is failing due to missing dotnet executable.

Ok I have to check that. Never have done something with the Github Build Pipeline.

vslavik · 2023-10-16T16:39:16Z

As a consequence, I have not changed the "original" nuget package (except moving from nuget pack to dotnet pack), but have added a second nuget package

This was not clear to me. And it's still not clear to me what is the new package created, how is it named, published etc.

I'm hesitant to maintain two packages just for the sake of this... If it's something I can easily add to the existing package, I'm all for merging it (it's not useful to me, but if it's other, why not), but if it's more maintenance work in the future, and more confusion, that's less clear to me.

And if I should provide different kinds of packages (which can be argued), why dotnet tool in particular, when e.g. winget or chocolatey seem more widespread?

martinbu · 2023-11-13T06:46:15Z

I will reopen this again, as soon as multiple package types are supported as documented- which is not the case at the moment.
As soon as this is possible, only one package can be published that additionally can be used as dotnet tool - as it was my initial thought.

vslavik requested changes Sep 1, 2023

View reviewed changes

Martin Burtscher added 2 commits September 4, 2023 16:00

martinbu force-pushed the feature-run-as-dotnet-tool branch from 3a1294b to 872d215 Compare September 4, 2023 14:22

martinbu changed the title ~~added initial implementation for using the nuget package as dotnet tool~~ Added dotnet tool support Sep 4, 2023

martinbu closed this Nov 13, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added dotnet tool support #12

Added dotnet tool support #12

martinbu commented Aug 30, 2023 •

edited

Loading

vslavik commented Sep 1, 2023

vslavik Sep 1, 2023

martinbu Sep 4, 2023

vslavik Sep 1, 2023

martinbu Sep 4, 2023

martinbu commented Sep 4, 2023

martinbu commented Sep 4, 2023 •

edited

Loading

vslavik commented Oct 5, 2023

martinbu commented Oct 9, 2023 •

edited

Loading

vslavik commented Oct 16, 2023

martinbu commented Nov 13, 2023

		@@ -0,0 +1,398 @@
		## Ignore Visual Studio temporary files, build results, and

Added dotnet tool support #12

Added dotnet tool support #12

Conversation

martinbu commented Aug 30, 2023 • edited Loading

vslavik commented Sep 1, 2023

vslavik Sep 1, 2023

Choose a reason for hiding this comment

martinbu Sep 4, 2023

Choose a reason for hiding this comment

vslavik Sep 1, 2023

Choose a reason for hiding this comment

martinbu Sep 4, 2023

Choose a reason for hiding this comment

martinbu commented Sep 4, 2023

martinbu commented Sep 4, 2023 • edited Loading

vslavik commented Oct 5, 2023

martinbu commented Oct 9, 2023 • edited Loading

vslavik commented Oct 16, 2023

martinbu commented Nov 13, 2023

martinbu commented Aug 30, 2023 •

edited

Loading

martinbu commented Sep 4, 2023 •

edited

Loading

martinbu commented Oct 9, 2023 •

edited

Loading