Support installing only specific commands and packages by aqua i's command line arguments

[suzuki-shunsuke]

Feature Overview

Support installing only specific commands and packages by aqua i's command line arguments.

Why is the feature needed?

Please explain the problem you want to solve.

To install only specific packages without executing them.

Workaround

There are three workarounds.

1. Run a command to install the package by Lazy Install
2. tag: https://aquaproj.github.io/docs/guides/package-tag/
3. split aqua.yaml

Sometimes we use the workaround 1, but this is a hack and looks weird. Ideally I don't want to run the external command to install it.

2 and 3 is verbose.

Does the feature include Breaking Changes?

No.

Example Code

command and configuration

$ aqua i go cli/cli

If the argument includes /, aqua treats it as the package name, otherwise aqua treats it as command.

[sheldonhull]

I've seen folks actually try to do this when I introduced them to the tool, as they assumed it worked like brew. If you do allow it then I suggest making a flag to --save or --persist or whatever you think works so it's clear that you can install, but there's an easy way to ensure it persists in the aqua.yaml.

[suzuki-shunsuke]

making a flag to --save or --persist or whatever you think works so it's clear that you can install, but there's an easy way to ensure it persists in the aqua.yaml.

I assumed that given packages were already added in aqua.yaml, and I didn't think to add packages by install command.

You suggest the flag that adds packages to aqua.yaml like aqua g -i and installs only given packages, right?

[sheldonhull]

If aqua isn't meant to handle one off installs, then I would propose installing a specific package by name should automatically persist that to the configuration file. Even though it may not be what other tools do it definitely aligns with aqua's approach about configurations as code.

If aqua was more like brew, then I would say no. However, the per project configurations seems to be the most mentioned. I use global configuration, but I'm fine with editing my config and running install afterwards.

I think having it persist in the project level configurations to guide users better to use aqua as intended.

[suzuki-shunsuke]

Let's assume that aqua i <package> is run in CI and the package isn't found in aqua.yaml.
If aqua i <package> adds the package to aqua.yaml and installs it, users can execute the package nevertheless the package isn't managed in aqua.yaml. The latest version of the package is always run.
This violates the policy of aqua's strict version control.
And if users misunderstand that the package is managed in aqua.yaml, it is difficult for users to find the misunderstanding because CI passes.

So I think if the package isn't found in aqua.yaml aqua i <package> should fail.