Different distributable URL for each platform

[krzyzanowskim]

Is there a way to set up different URLs for each platform (Darwin/Linux)?

something along the way:

distributable:
  darwin:
    url: https://github.com/pkgxdev/darwin/brewkit/archive/refs/tags/v{{ version }}.tar.gz
  linux:
    url: https://github.com/pkgxdev/linux/brewkit/archive/refs/tags/v{{ version }}.tar.gz

[jhheider]

there's not. it'd be unusual to have different sources for different platforms, but not impossible. you'd more likely be loading an sdk or something else such as flutter.dev where you curl a specific archive based on env. or you can use a git url to check out the whole repo and go from there.

[krzyzanowskim]

it'd be unusual to have different sources for different platforms, but not impossible

unusual, and a thing I'm dealing with

That has another implication, that is versioning may be different for each platform, eg 1.0.0 is available for darwin, but 0.9.0 for linux - such disparity happens. Is there a workaround to handle that? (also happens in real)

[jhheider]

what package are we talking about? it sounds like maybe those need to be different packages?

[krzyzanowskim]

swift pkgxdev/pantry#4840

[jhheider]

Ah, yes. Swift is a tough one. We've looked at packaging swiftup (iirc), and tried packaging swift builds. Might need to be two packages. Maybe swift.org/platform?

[krzyzanowskim]

Maybe swift.org/platform?

is this a convention used elsewhere? I'm thinking how discoverable is it

[jhheider]

It's not. Swift will be the first package that requires this.
@mxcl as a life-long swift adherent, what options would you explore here?

[mxcl]

k the referenced package is not building from source, it is using a pre-built (but freely distributable) vendor built package.

Unless I'm mistaken?

We do want to support this. We have this PR to do the same for rust for example. We also do the same for bun already since it required a custom build of zig to build from source and that was super early so we just punted on it.

In general I am fine with using vendored sources as long as we trust the vendor. Ideally the vendor will sign the sources with GPG (or something better) and ofc Apple do so!

So let me finish of the vendoring YAML shape and mechanism. Or in the meantime you can copy what we do with bun and curl the vendor’d binary in the build script.

---

Different versions for different platforms? That however is more problematic and not something we have seen before. While on the one hand it makes perfect sense that fixes or additions may be platform specific, in general open source just tags the version for all platforms anyway. I'll look deeper.

[krzyzanowskim]

I think I manged per platform setup of vendored swift binaries. I struggle with the linux runtime tho https://github.com/pkgxdev/pantry/actions/runs/7520712858/job/20470685734?pr=4840 where it requires certain glibc, and now I'm not sure how to handle that situation. Vendored package is made for a distribution and version, it probably won't work properly everywhere. the pkgdev/pkgx docker image seems to be Debian GNU/Linux 10, and now, how do I restrict linux package to these supported?

[mxcl]

linux pkgx has some “pre requisite” deps, the main one is glibc >=23.

We aim to provide these ourselves eventually, but currently that's the state of it. Swift for Ubuntu 18.04 is provided by Apple and that has the right glibc so I've been trying to get our swift package yml to use that.