
Swift package manager - famoreira
https://github.com/apple/swift-package-manager
======
andrewbarba
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...](https://github.com/apple/swift-package-
manager/commits/master?page=4)

~~~
tadfisher
He is now employed by Apple.

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

~~~
robmcm
Lets just hope there aren't any binary trees in need of inverting at Apple ;)

Seriously though, seems like a perfect fit, much better than him working on
something unrelated at Google etc

~~~
pjmlp
As an Android hobby developer, given the amount of issues that have been
lagging all these years and the quality of each "stable" release, I really
don't get where do all those genius that Google does eventually hire work.

~~~
legulere
Optimizing ad revenue.

~~~
robmcm
and not working for other companies

------
Sanddancer
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.

~~~
rimantas
So, do you manage cocoapods or carthage for your iOS/OS X developers right
now? Go away and rant how all languages except one your favourite should be
banned, because that would make ops job so much easier. Though I am still not
sure what ops are doing on developers' machines.

~~~
Sanddancer
No, I don't want languages banned, I want them to stop reinventing the package
management wheel. Why the bloody hell does apple need to release a package
manager for swift, with its own new format, when, as you pointed out,
cocoapods already exists? Why a new, completely incompatible format?

The current state of the world means that it is currently entirely feasible
that some components will be managed by cocoapods, and some by this new
format. What world-shattering difference between the two exists such that they
can't share a metadata format to describe a development package? How does the
new format make life easier?

------
thinkingkong
And its not called Taylor?

~~~
giancarlostoro
I certainly wouldn't mind if it was called Tailor instead... :)

------
jacques_chester
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](https://github.com/kylef/heroku-buildpack-swift)

[2] [https://blog.starkandwayne.com/2015/12/08/apple-swift-
buildp...](https://blog.starkandwayne.com/2015/12/08/apple-swift-buildpack-
for-cloud-foundry/)

------
shadowmint
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.

------
vikrantpogula
Finally !

