Swift Package Manager

[Herby G]

> Otherwise MacPorts could just run Artifactory or something to cache and
serve dependencies and all would be good.

Having MacPorts run asset servers or repositories for all the different
languages and frameworks out there (like running Artifactory) would be
immensely unsustainable.

On Fri, Dec 18, 2020 at 3:39 AM Nils Breunese <nils at breun.nl> wrote:

> Ryan Schmidt <ryandesign at macports.org> wrote:
>
> > A build system that forces fetching from a specific upstream server
> reduces our ability to build on older systems, since that specific server
> might have https requirements that older system can't meet. We need to be
> able to mirror files on our servers so that older MacPorts clients can
> download from them.
> >
> > Tying us to a specific upstream server also ties us to the reliability
> of that server. If it goes down, we go down, and users flood us with bug
> reports about it. We don't want that.
>
> It’s really too bad that even a lot of modern build tools do not have the
> concept of proxyable, cachable) repositories for dependencies. For instance
> for builds that use Maven repositories (Maven, Gradle and some other build
> tools in the Java ecosystem) you can set up your own proxy which fetches
> dependencies when first requested from upstream, stores them for future use
> and lets you control HTTPS settings, availability, etc. This all works
> because dependencies are not identified by a full URL. I believe NPM
> repositories will let you do the same thing for the JavaScript ecosystem.
>
> The pain comes when build tools don’t use a proxyable, cachable repository
> concept (Go, etc.). Otherwise MacPorts could just run Artifactory or
> something to cache and serve dependencies and all would be good. Currently
> MacPorts is bolting this concept onto build tools that don’t have it, and
> that is indeed daunting and cumbersome.
>
> Nils.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20201219/d1a786dd/attachment.htm>