Ryan Schmidt <[email protected]> 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.
