feat: SPM(Swift Package Manager) backend

[kattouf]

Implementation of backend for install executables managed by Swift Package Manager

Description

Discussion Compared to previous PR there are no dependencies on third parties other than Swift itself.

SPM does not support installing an executable, only the build command. This backend implementation itself covers this functionality and is described by a flow:

1. Clone the repository with the SPM package into a temporary directory.
2. Read Package.swift for a list of executables
3. Build each executable and copy the binary with associated resources to mise install directory

Demo screenshots:

P.S. I'm not full-time Rust developer, feel free to make comments if something is not done according to best practices in Rust community

Requires attention

1. Missed swiftdependency I had some problems installing swift with the current asdf plugin so I guess we'll just have to wait for https://github.com/jdx/mise/pull/1708 Now missed dependency leads to:
   • Unable to run e2e test
   • Users are responsible for installing swift
2. Support for build artifacts on other platforms I have no experience using swift on other platforms (Linux, Windows) and can't be sure about finite list of resource and dynamic libraries formats we should support to copy together with binary. I decide dive into it after we are sure that everyone is happy with the feature and we will discuss merging it.
3. Name of package to install
   1. I don't sure about how flexible it should be, so for now I limited it to two options:
      • GitHub repo name: spm:nicklockwood/SwiftFormat@0.53.10
      • GitHub https url: spm:https://github.com/nicklockwood/SwiftFormat.git@0.53.10 Maybe we should add other options by community requests
   2. When we use different formats for the same package repo, they are perceived as different packages:

      I got some errors when trying to change the BackendArg name to generic format (shortened) in SPMBackend::new(name) Are there any other options to solve this problem?

4. Versioning Current implementation looking for GitHub release tags for installation candidates. Installation by branch/commit can also be supported, but I'm not sure if this should be done now.

[kattouf]

@pepicrft Could you also check Requires attention section in PR description? None of this seems like a blocker to you right now? We have already partially discussed points 3 and 4, so you can focus on 1, 2 and 3.ii

[pepicrft]

1. Missed swift dependency

I'd be consistent with what the other backends do. If they install the required toolchain absent, we can error out telling users that "Swift was not found in the environment" until we install it ourselves. This is a scarce scenario because most developers using this backend will likely be Xcode developers with the toolchain available in their systems.

2. Support for build artifacts on other platforms

I'm in a similar spot here. At least on Linux, if everything is statically linked, the binary should work, so the issues will likely arise when using dynamic dependencies, which I'm not entirely sure are supported on Linux. Similarly, this is a bit uncommon, so I'd ship this as it is and iterate on it as feedback comes our way.

3. When we use different formats for the same package repo, they are perceived as different packages

This is a bit confusing, especially considering that they are referring to the same package. @jdx might be able to help with this one.

[kattouf]

I'd be consistent with what the other backends do.

Currently mise doesn't automatically install backend dependencies, instead the documentation suggests installing them using mise or any other convenient method and gives an error message:

It seems that the backend is a feature that expects that it will be used by those people who already have the entire necessary tools, they just want to describe them in a single config

Similarly, this is a bit uncommon, so I'd ship this as it is and iterate on it as feedback comes our way.

Agree 🤝

[pepicrft]

Overall, fantastic work @kattouf 👏🏼. As one of the advocates of Mise in the Swift ecosystem, I couldn't be more excited of this work landing. We have to wait for @jdx to do the merge.