-
Notifications
You must be signed in to change notification settings - Fork 239
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Mint(swift) backend #2199
Conversation
22bc821
to
23ea1a3
Compare
I wonder if we should have the logic in Mise instead of proxying through another tool. The logic would be comprised of:
Thoughts @jdx ? |
It looks like interesting task! But in my vision, In our case, I think we could contribute to Mint and get profits for both Mise and Mint users at once 💪 |
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:
I think the Go and Cargo are good examples of that, and there could be an |
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 Then I looked at your original message from a new perspective and I think your idea is promising 👍 |
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. |
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. |
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. |
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. |
@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: |
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. |
Closed in favor of #2241 |
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:
Result:
WIP / Questions:
Need to update documentation / cli help?
Dependencies: The
Mint backend
depends onMint
, which at runtime, in turn, depends onswift-lang
. Currently, neither can be installed bymise
: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:
Mint
this way? (For example, liketest_ubi
).(Currently,
Mint
doesn't have any installation scripts for use outside the repository).Mint
dependencies as well? (Swift language).