Re: Sandbox issues with Swift Package Manager

Ah ok , that's above my paygrade right now - I had no idea we were doing that. I've copied the dev list - I think the response will be better over there. —Mark ___ Mark E. Anderson MacPorts Trac WikiPage GitHub Profile

Re: Swift Package Manager

stand why Apple's > https being outdated is causing problems for MacPorts. Doesn't MacPorts try > to use it's own versions of things anyway? > > So, MacPorts could: > > 1. Install its modern version of OpenSSL (which supports all modern HTTPS > features). > 2. Lin

Re: Swift Package Manager

Ports try to use it's own versions of things anyway? So, MacPorts could: 1. Install its modern version of OpenSSL (which supports all modern HTTPS features). 2. Link Swift Package Manager to Macports's OpenSSL. Perhaps step 2 is more complicated than I'm imagining in my head? I mean,

RE: Swift Package Manager

fied by a full URL. I believe NPM > repositories will let you do the same thing for the JavaScript ecosystem. Does anyone know whether Swift Package Manager supports an offline cache, similar to Cargo’s ‘—offline’ option? That would allow us to take a point-in-time snapshot of the download/dependency c

Re: Swift Package Manager

Herby G wrote: > > 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 > immens

Re: Swift Package Manager

> 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 1

Re: Swift Package Manager

Ryan Schmidt 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

Re: Swift Package Manager

On Dec 17, 2020, at 09:29, Ken Cunningham wrote: > we are not likely to win this...we accept the package manager when it cones > to ghc/stack, We don't really. Having an updated working ghc/stack for some systems was better than not having it for any systems, but it sucks and needs to be fix

Re: Swift Package Manager

we are not likely to win this...we accept the package manager when it cones to ghc/stack, and doing this has added a formidable amount of complication to the go ports that is daunting for contributors and maintainers... Perhaps we just forget about doing this with ghc /go / swift and friends? I

Re: Swift Package Manager

On Dec 17, 2020, at 08:17, Aaron Madlon-Kay wrote: > A port I maintain, Sequel-Ace, has recently switched from including a > dependency with CocoaPods (which vendors all dependency code alongside the > main project in the same repo) to Swift Package Manager (which fetches at >

Swift Package Manager

Hello all. A port I maintain, Sequel-Ace, has recently switched from including a dependency with CocoaPods (which vendors all dependency code alongside the main project in the same repo) to Swift Package Manager (which fetches at build time): https://github.com/Sequel-Ace/Sequel-Ace/pull/586