install --binary, -b about mint HOT 15 OPEN

Having access to a pre-built binary would be great, but many repo's simply don't supply it, and there are no standards around this. Mint is designed to work with any Swift PM repo, with 0 work from the maintainer. (The Package.resource file is an exception to this, but only because it's optional and something that SwiftPM can't provide.)
Some packages also include multiple executables (like SwiftPM itself), which complicates the potential "standard" release script.

Having said all that, we could potentially check the github release for a zip that has the same name as the executable the user is trying to install, and then document that. The whole contents of that zip could then be put into the directory the build package would. This also solves the resources problem in a different way, as they are explicitly packaged. You're welcome to submit a PR for this 👍

from mint.

@toshi0383 I would think downloaded binaries and other files would go to the same place build binaries they do now. Global installs are then still symlinked in/usr/local/.

from mint.

@acecilia maybe https://github.com/swiftbrew/Swiftbrew could help you out?

from mint.

Understood!👌
And before creating the zip file, I know we need to change @rpath of the executable for swift toolchain and for dyld loading path, using install_name_tool.

Because

• Some users may have default Xcode in different location or name.
• obj-c or c library cannot be embedded in executable using -static-stdlib option.

from mint.

I don't know since when, but Swift now embeds C and objc libraries directly.
So I guess latter workaround isn't necessary anymore.

from mint.

👍 Since Swift 4

from mint.

I'm considering about where to put downloaded binaries and resources(man-pages and assets from Package.resources). Whether it should be symlinked or just overwrite existing under /usr/local/.

@yonaskolb What do you think?

from mint.

As I've commented in yonaskolb/XcodeGen#234 (comment) , in CI there is no point to use mint for binary install. (because user need to build mint at first anyways.)
So I guess we can just recommend users to use standalone script(like mine) to perform binary install. (At least I would use my install.sh.)

@yonaskolb Thoughts?

from mint.

Yeah, if you’re simply installing binaries it’s really got nothing to do with Mint, Swift or Swift PM. Just a normal script will do 👍

from mint.

I'm still seeing some value in this actually.

For example

mint install realm/[email protected] --github-binary portable_swiftlint.zip/swiftlint

Would look if:

• the repo is on github
• look if the binary is attached to the tag
• if it's a zip unzip it
• fine the binary at the path (could default to the name)
• copy as normal

from mint.

Originally I thought you meant an automatic way of finding binaries, which we can't do. Having it as an optional argument though works

from mint.

What is the status of this @toshi0383 ?

I find it super useful, for example if you have 4-5 mint dependencies, building them will take forever, downloading precompiled binaries will be a breeze. And we will have a "standard" way of doing it, instead of having to use scripts :D

from mint.

Wow this has been inactive long time, sorry.

As we discussed so far, with the interface like this,

mint install author/[email protected] --github-binary portable_tool.zip/tool

under the hood mint would do like this, right?

curl https://github.com/path/to/the/binary.zip -o tool.zip
unzip tool.zip
cp tool/tool /usr/local/bin/tool

I think we still have to consider issues like:

• other resources needed to be copied as well
• need to verify hash of the zip file (for security)

To resolve these, basically library author end-up with customized install.sh. (like XcodeGen)

And even if we address these features, how do you trust the binary provided by third-party library author, right?

I see Homebrew does that by providing central repository and server to build binary (bottles) for each version automatically.

So I think we have two choices:

• Go as far as homebrew's binary distribution workflow
• Stay where we are and stick with install.sh which you trust.

@acecilia Any other ideas?
I also thought that maybe you can use CI's cache feature, too?

from mint.

Yeah, I see the main issue is the security part of it: how do you trust the binary provided by third-party library author, right?

I guess in that case we can only go for second option you mentioned, as we do not have infrastructure for the first one.

from mint.

I checked it out, but seems it does not support catalina looking at the existing issues. But thanks for pointing out!

from mint.