Added no_overwrite flag in LibraryInstall

[cmaglie]

Please check if the PR fulfills these requirements

• The PR has no duplicates (please search among the Pull Requests
  before creating one)
• The PR follows
  our contributing guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• UPGRADING.md has been updated with a migration guide (for breaking changes)

What kind of change does this PR introduce?
Added a flag to lib install to skip library install if the library is already installed (no upgrades or downgrades)

What is the current behavior?
The library is installed, possibly replacing another version already installed.

What is the new behavior?
If the no_overwrite flag is set the installation is aborted if the installed library will replace another already installed library.

Does this PR introduce a breaking change, and is titled accordingly?
no

[per1234]

How about switching the flag to something like --overwrite and inverting the logic?

This type of interface where you have to use a double negative to get a true is not terribly intuitive.

[per1234]

I'm reconsidering my previous suggestion because:

• Since the "overwrite" behavior is the current default, the typical use case for the flag under the current Arduino CLI behavior would be --overwrite=false, which is kind of awkward.
• As for changing the default behavior, I did a quick survey of dependencies management tools and found that Arduino CLI's current default is not so unusual (both go get <module> and npm install <package> will upgrade a previously installed dependency, while pip install <package> and poetry add <package> do not upgrade).

See comment above

[per1234]

It would be good to add test coverage of dependencies handling, including custom version constraints.

[per1234]

The behavior when there are custom dependency version constraints is not as I expected.

The library [email protected] has the following depends field:

depends=Bounce2 (>=2.53)

My expectation is that if [email protected] is already installed, installation of [email protected] will:

• Install the EncoderTool (because the currently installed version of the dependency matches its constraint)
• Not update the Bounce2 library

But the installation fails:

$ arduino-cli version
arduino-cli.exe  Version: git-snapshot Commit: 0ad48e07 Date: 2022-07-08T10:52:47Z

$ arduino-cli lib install [email protected]
Downloading [email protected]...
[email protected] downloaded
Installing [email protected]...
Installed [email protected]

$ arduino-cli lib install --no-overwrite [email protected]
Error installing EncoderTool: Library [email protected] is already installed, but with a different version: [email protected]

[cmaglie]

The behavior when there are custom dependency version constraints is not as I expected.

I see and you're right with your expected output. As it is now the --no-overwrite flag is not affecting the library dependencies resolution, it just stops the install if the "solution" found by the resolver will change at least one of the libraries.

To achieve your request we need to change how the resolver behaves, BTW this change it's quite involved and requires more work on the library dependencies resolution part. We need to:

• give the status of the currently installed libraries to the resolver
• ask the resolver to keep the already installed libraries at their version this means that
  • if a dependency is mentioned in a constraint expression we must either:
    • synthesize another constraint that forces the mentioned library to stay at the current version, or
    • pick the mentioned library at the current version as part of the solution
• merge some pending PR on the semver library:
  • Consider compatible-with ^ constraint implicit if operator is missing bugst/relaxed-semver#10
  • I've another one (not yet published) that adds resolution strategies to the resolver.
  • I've another one (not yet published) that simplifies the API using generics
    • but this one requires that we adopt go1.18 first

So for now I think we can postpone this to a future release since it will not be a breaking change but an improvement to the currently available commands.

If you agree, I would ask you to move the example above to a new issue.