TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Swift package manager

69 点作者 famoreira超过 9 年前

7 条评论

andrewbarba超过 9 年前
I was really excited to see Mattt Thompson (AFNetworking &amp; 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.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;apple&#x2F;swift-package-manager&#x2F;commits&#x2F;master?page=4" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;apple&#x2F;swift-package-manager&#x2F;commits&#x2F;maste...</a>
评论 #10702811 未加载
mlex超过 9 年前
It&#x27;s seriously so cool that the Homebrew guy (Max Howell) is behind this. Great fit for him at Apple. =P
评论 #10702964 未加载
评论 #10702986 未加载
Sanddancer超过 9 年前
Okay, I&#x27;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?<p>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&#x27;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&#x27;t reuse for the other ten languages you&#x27;ve gotten on your system.<p>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&#x27;ll make your job a ton easier, and you&#x27;ll make ops&#x27; job a ton easier.
评论 #10702538 未加载
评论 #10703248 未加载
评论 #10702587 未加载
评论 #10703744 未加载
评论 #10702582 未加载
评论 #10702753 未加载
thinkingkong超过 9 年前
And its not called Taylor?
评论 #10702321 未加载
评论 #10703056 未加载
jacques_chester超过 9 年前
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].<p>Speaking of my own experience in working on Cloud Foundry buildpacks, a feature I&#x27;d be keen on having is true &quot;vendoring&quot; of dependencies. Bundler does this correctly with a common corner case -- gems that include C&#x2F;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.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;kylef&#x2F;heroku-buildpack-swift" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kylef&#x2F;heroku-buildpack-swift</a><p>[2] <a href="https:&#x2F;&#x2F;blog.starkandwayne.com&#x2F;2015&#x2F;12&#x2F;08&#x2F;apple-swift-buildpack-for-cloud-foundry&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.starkandwayne.com&#x2F;2015&#x2F;12&#x2F;08&#x2F;apple-swift-buildp...</a>
shadowmint超过 9 年前
All it does is git clone tagged network git repos and invoke swiftc.<p>No support for tests yet, beyond ignoring folders called &#x27;Test&#x27;. It can&#x27;t even support local file paths at the moment.<p>Certainly, watch this space, but there&#x27;s hardly anything to be excited about here yet.
vikrantpogula超过 9 年前
Finally !