feat: Mint(swift) backend

[kattouf]

Implementation of custom backend based on Mint: A package manager that installs and runs executable Swift packages

Motivated by discussion

Mint works in a simple way: it looks for release tags, checkout the specified one, and compiles the executable target.

The following environment variables are available to configure the installation path: MINT_PATH, MINT_LINK_PATH.

From the README:

You can set MINT_PATH and MINT_LINK_PATH environment variables to configure where Mint caches builds, and where it symlinks global installs. These default to ~/.mint and ~/.mint/bin respectively.

Result:

WIP / Questions:

• [ ] Need to update documentation / cli help?

• [ ] Dependencies: The Mint backend depends on Mint, which at runtime, in turn, depends on swift-lang. Currently, neither can be installed by mise:

  • Mint does not have a plugin and cannot be installed by any other backend.
  • Swift has a plugin, but the last time I tried it, it didn't work. This needs to be double-checked. UPD: also pr can be useful here

  So the question is: do we need to implement plugins for all dependencies first, to use them from the backend? Or dependencies free implementation fits too?

• [ ] End-to-end test:

  • Can I pre-install Mint this way? (For example, like test_ubi). (Currently, Mint doesn't have any installation scripts for use outside the repository).
  • Should I pre-install Mint dependencies as well? (Swift language).

[pepicrft]

I wonder if we should have the logic in Mise instead of proxying through another tool. The logic would be comprised of:

• Running swift build to generate the binaries.
• Look up the binaries in the conventional build directory
• Copy those artifacts to the location where Mise expects them.

Thoughts @jdx ?

[kattouf]

if we should have the logic in Mise instead of proxying through another too

It looks like interesting task!

But in my vision, mise should be a just facade and contain only knowledge on how to work with other tools. This approach ("facade") makes it easy for everyone to switch to and from mise and prevents mise from becoming a "super builder" with a lot of knowledge about different technology stacks details, duplicating logic already written in other community respected and used tools.

In our case, I think we could contribute to Mint and get profits for both Mise and Mint users at once 💪

[pepicrft]

I have a different opinion, but I'm not too intense about it.

Mise should not replace an underlying build tool, like Cargo, SPM, or Go's toolchain, because it's not its responsibility, but shelling out to a tool that does the same as Mise, invoking a build tool, SPM, in this case, feels unnecessary indirection, which comes with some drawbacks:

• Issues are harder to debug.
• Mise loses control over the output formatting and errors, which are now propagated through an additional layer.
• It requires users to have an additional tool in their system.

I think the Go and Cargo are good examples of that, and there could be an SPM forge that takes a similar role for Swift packages. If it was costly, I'd disagree with re-building the functionality, but most of what Mint does, is already implemented by Mise, so it's very low cost.

[kattouf]

Thank you for clarification, I misunderstood you at first. Now i think we have similar vision 🤝

I was a little confused by the fact that Rust and Go have built-in methods for installing executable files, unlike SPM. But after thinking a little, I realized that swift "install" is would be just checkout release tag && swift build && copy built binary, simplifying.

Then I looked at your original message from a new perspective and I think your idea is promising 👍 I could try to do this if @jdx also likes this approach

[jdx]

I'd actually like it if you made the decision @pepicrft, you're the chief swift expert on the team after all.

I think there are merits to both perspectives. I think there is a maintenance benefit that will make my life easier by using mint, however using mint introduces a bootstrapping problem—there isn't a good way to setup mint itself. Perhaps we could inline the installation of mint if it might make #1708 simpler and make it hidden to the user. I'm open to whatever you think is the best long-term plan here.

[pepicrft]

I'd like to give it a shot at implementing the forge for Swift, and if the maintenance cost is low, I'd suggest that we keep that one. At the end of the day, any Swift repository that's manageable by Mint, should be manageable by Mise too.

[jdx]

this is a tangent, but my experience with swift is very basic and mostly limited to reading about the basic design, I think it's one of the most incredible languages out there and I don't understand why it seemingly isn't used out of the apple ecosystem. It really seems like it could be an ideal language for CLI tools—far better than Go and much easier to learn than Rust while I assume has similar performance characteristics.

[pepicrft]

If it weren't for the strong focus on Apple platforms, we'd see the language thriving on other platforms. Apple is making some good progress there by open sourcing its Foundation framework, but they have a long way to go still.

[kattouf]

@pepicrft Did I understand correctly that we are now making a “native” version of forge and then comparing both versions? if so, then I would start trying it in a new branch and then open a another pr

UPD: Ok, I think it is, so I've already started work on new backend 🙂

[pepicrft]

Ok, I think it is, so I've already started work on new backend 🙂

Oh! This is very nice :). Let me know when it's ready, and I can review it. That work, along with this one, which I started some time ago, should make Swift well-supported by Mise.

[kattouf]

Closed in favor of https://github.com/jdx/mise/pull/2241