5 ms·

Swift package manager

69 points by famoreira 11y ago

thinkingkong 11y ago
And its not called Taylor?
- giancarlostoro 11y ago
  I certainly wouldn't mind if it was called Tailor instead... :)
- agildehaus 11y ago
  Already taken: https://github.com/izqui/Taylor https://github.com/izqui/Taylor
mlex 11y ago
It's seriously so cool that the Homebrew guy (Max Howell) is behind this. Great fit for him at Apple. =P
- robmcm 11y ago
  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 11y ago
    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 11y ago
      Optimizing ad revenue.
      - robmcm 11y ago
        and not working for other companies
  - glhaynes 11y ago
    For those who might not get the reference: https://twitter.com/mxcl/status/608682016205344768?lang=en https://twitter.com/mxcl/status/608682016205344768?lang=en
- stephenr 11y ago
  Having used Homebrew, I can just say I'm glad I don't write swift code, because if this turns out anything like that, ugh.
andrewbarba 11y ago
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/master?page=4 https://github.com/apple/swift-package-manager/commits/maste...
- tadfisher 11y ago
  He is now employed by Apple.
Sanddancer 11y ago
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.
- legulere 11y ago
  > We have rpm, deb, pkg, pkgng, etc as system packaging formats. Those are all general binary distribution formats: they copy certain files as root to a predefined position in the file system and execute code as root. Not at all the use case for this: Downloading library source files that are needed for building something as a user. It actually also uses pre-existing things: "a package is a git repository with semantically versioned tags, that contains Swift sources and a Package.swift manifest file at its root."
- rimantas 11y ago
  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.
vikrantpogula 11y ago
Finally !
shadowmint 11y ago
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.
jacques_chester 11y ago
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-buildpack-for-cloud-foundry/ https://blog.starkandwayne.com/2015/12/08/apple-swift-buildp...

69 points by famoreira 11y ago

thinkingkong 11y ago

And its not called Taylor?

giancarlostoro 11y ago
I certainly wouldn't mind if it was called Tailor instead... :)
agildehaus 11y ago
Already taken: https://github.com/izqui/Taylor https://github.com/izqui/Taylor

mlex 11y ago

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

robmcm 11y ago
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 11y ago
  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 11y ago
    Optimizing ad revenue.
    - robmcm 11y ago
      and not working for other companies
- glhaynes 11y ago
  For those who might not get the reference: https://twitter.com/mxcl/status/608682016205344768?lang=en https://twitter.com/mxcl/status/608682016205344768?lang=en
stephenr 11y ago
Having used Homebrew, I can just say I'm glad I don't write swift code, because if this turns out anything like that, ugh.

andrewbarba 11y ago

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/master?page=4 https://github.com/apple/swift-package-manager/commits/maste...

tadfisher 11y ago
He is now employed by Apple.

Sanddancer 11y ago

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.

legulere 11y ago
> We have rpm, deb, pkg, pkgng, etc as system packaging formats. Those are all general binary distribution formats: they copy certain files as root to a predefined position in the file system and execute code as root. Not at all the use case for this: Downloading library source files that are needed for building something as a user. It actually also uses pre-existing things: "a package is a git repository with semantically versioned tags, that contains Swift sources and a Package.swift manifest file at its root."
rimantas 11y ago
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.

vikrantpogula 11y ago

Finally !

shadowmint 11y ago

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.

jacques_chester 11y ago

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-buildpack-for-cloud-foundry/ https://blog.starkandwayne.com/2015/12/08/apple-swift-buildp...