Should CLI tools be consolidated into one?

[JordanMarr]

Rather than having separate packages:

• SqlHydra.SqlServer: dotnet sqlhydra-mssql
• SqlHydra.Npgsql: dotnet sqlhydra-npgsql
• SqlHydra.Oracle: dotnet sqlhydra-oracle
• SqlHydra.Sqlite: dotnet sqlhydra-sqlite

It seems like it would be more convenient to just have one package to rule them all:

• SqlHydra.Cli:
  • dotnet sqlhydra mssql
  • dotnet sqlhydra npgsql
  • dotnet sqlhydra oracle
  • dotnet sqlhydra sqlite

Since it's a dotnet tool that isn't included directly as a sln project, it shouldn't really matter if it references multiple db provider packages. It would also reduce the amount of project maintenance in terms of conditional dependencies to tweak during .NET version upgardes, versions to set when deploying, duplicate info on the readme page, etc.

The downside would be fairly minimal (swapping to new tool and removing - from the command name).

Am I overlooking any big issues with this approach?

[JordanMarr]

Still can't decide on whether to consolidate the generator tools into one. ping @MangelMaxime: do you have an opinion on this?

[MangelMaxime]

Hello @JordanMarr thanks for the ping.

I think for a CLI tool both approach are valid. However, as a maintainer I know the cost of having several times the same project to maintain and it can be a real pain.

Looking at you Fulma and your 15 packages 😅.

When you make a change on a dependency you need to make it happens everywhere and change all the changelog which are out of sync because they have different versions etc.

All that to say, having a single package is probably the path to an easier maintenance over time.

Since it's a dotnet tool that isn't included directly as a sln project, it shouldn't really matter if it references multiple db provider packages.

Reading this question made me think of Grate. This is a SQL scripts migration runner written using .NET and it supports different database at the same time.

You can see here that it depends on different provider/connectors packages.

While skipping really really fast through the code I didn't see any obvious hacks/limitations coming from the multiple provider thing.

Personally, I prefer the readability/typing experience of dotnet sqlhydra mssql. And from a user point of view, I think having a CLI lower entry cost as the user have one less decision to make.

After writing the end of my comment, I guess I am leaning toward the single CLI if there are no major hacks/complexity to add in the code base.

[JordanMarr]

I appreciate your thoughtful analysis.

Another thing that I kind of regretted was that I don't think I needed to explicitly add a net7 target framework. I did so on request, but in hindsight, I think net6 would have worked for both, since I wasn't utilizing any new features. Between the multiple packages and multiple target frameworks (net5-net7), it makes testing and deployment take a really long time. Consolidating would allow me to target only net6. (Dropping net5 will remove a lot of conditional code that supports the new DateOnly and TimeOnly types that were added in net6.)

[MangelMaxime]

I never quite understood how version compatibility worked in .NET but I think in general it is best to stay on LTS unless you are using a new feature.

Following this rule, it also detect when to drop support for old version when they come to end of life. Problem, is that sometimes if you support all LTS you would still end up with multi frameworks because LTS supports always (I think) overlap for 1 year.

it makes testing and deployment take a really long time.

I am not too much concern about deployment taking a long time as you can do something else during that time.

But for testing, depending how it is done indeed this can be annoying. Especially, if not everything is automated and you have to do it manually.