package subcommand has a lot of options for different package types, should these be sub-subcommands?

[rmgk]

The following is accepted by scala-cli without complaints:
scala-cli package --license "a" --exit-dialog "b" --docker-from "c" --graalvm-version "d" .
What does it do? Well, it ignores all the options, because the first is for RPM packages, the second for Windows installers, the third for docker, and the last for native image.

In my opinion, the issue is that the different package formats are not selectable arguments, but rather each format has its own set of possible arguments (the package --help even groups them by the packaging mode).
So maybe it would be beneficial to have something along the lines of:

scala-cli package jar ...
scala-cli package docker ...
scala-cli package deb ...
scala-cli package native-image ...

It still could be useful to have the separate arguments for --js and --native as those are different Scala outputs that are combinable with at least many of the above packaging modes (i.e., it would be possible to have a --js docker image --native deb).
Maybe it would then also make more sense to name the first example something more generic package bundle or something (instead of jar) to make it also work for --js and --native, but maybe package jar, package js, and package native could also be each their own subcommands.

This discussion is motivated by my recent struggles with packaging options:
#1793
#1783

[tgodzik]

Thanks for raising this! We'll need to discuss it with the team, but I do understand your issue.

[JD557]

Just wanted to add here that, not only do I agree with the above, but I think it would be nice to not have a default package format.

I admit that I only used package for JS and Native applications, so my understanding can be wrong, but having the default being a bootstrap script that downloads the dependencies seems like a bit weird (I would expect a package to work offline)... I understand the advantages of doing that vs a fat jar, but I think a user should be forced to explicitly make that decision.

Another point (regarding the docker question above), I think there are two axis here that should probably be split:

Target format:

• JVM bootstrap
• JVM assembly
• JVM library
• GraalVM
• JS
• Native

Distribution method:

• Plain file
• Docker
• OS-package

I think it would be OK if the distribution method was a flag, with a plain file being the default.