Swift package manager

  • I was really excited to see Mattt Thompson (AFNetworking & NSHipster) have quite a few commits in the repository. I followed him religiously when he would write for NSHipster and then he just kind of disappeared for a while (or I have no clue where to look). Regardless, great to see Apple looked to him for advice on this project seeing he has produced some of the most popular open source software for iOS and OS X that I know of.

    https://github.com/apple/swift-package-manager/commits/maste...

  • It's seriously so cool that the Homebrew guy (Max Howell) is behind this. Great fit for him at Apple. =P

  • Okay, I'm gonna have to enter rant mode here, because this is aggravating me. Why in the bloody fuck do we need another package format? Okay, cool, you have a project, it has needs, you wanna track it. How hard is it to use one of the pre-existing formats? We have rpm, deb, pkg, pkgng, etc as system packaging formats. Is your language such a precious and delicate flower that it needs its own packaging format? You can even use your own binaries to manage the bloody database, but can we get people to agree on some sort of standard here?

    This makes administration non-fun. It means needing to run a separate binary for every single package to audit for any sort of language change. It means that a project that uses multiple languages now needs multiple packaging databases to do its job. Which means that auditing is now much, much more difficult, because you have to go into each project's database, figure out what language it is, then call its database packager to get a list of packages and versions, and parse it with code you can't reuse for the other ten languages you've gotten on your system.

    So, before you start creating the next big package manager, please, for the sake of your ops people everywhere, see if someone else has already made a sensible packaging format. Chances are that they have, and by reusing their work, you'll make your job a ton easier, and you'll make ops' job a ton easier.

  • And its not called Taylor?

  • I see that there is already a Heroku buildpack for Swift, based on the package manager[1] and it was ported to Cloud Foundry[2].

    Speaking of my own experience in working on Cloud Foundry buildpacks, a feature I'd be keen on having is true "vendoring" of dependencies. Bundler does this correctly with a common corner case -- gems that include C/C++ code. It will keep that source code, as well as ruby. Turns out to be a very important feature when deploying to a disconnected environment.

    [1] https://github.com/kylef/heroku-buildpack-swift

    [2] https://blog.starkandwayne.com/2015/12/08/apple-swift-buildp...

  • All it does is git clone tagged network git repos and invoke swiftc.

    No support for tests yet, beyond ignoring folders called 'Test'. It can't even support local file paths at the moment.

    Certainly, watch this space, but there's hardly anything to be excited about here yet.

  • Finally !