https://github.com/apple/swift-package-manager/commits/maste...
Seriously though, seems like a perfect fit, much better than him working on something unrelated at Google etc
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.
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."
However, I do think you have a valid point in that there are plenty of commonalities between the software module package management needs of different languages. There is little need for each language to re-invent its own system.
It certainly would be considerably more challenging to develop a system that could work for multiple languages, and then there are the existing ecosystems to consider in terms of (the huge) cost of migration, mindshare, etc.
But in principle, you are right, even if economics means that it cannot happen in practice. No need for Yet Another One. But it will happen because economics.
It distributes source code and the audience is developers wanting to integrate that into their projects at build time.
Using something like RPM or DEB for that task would be, uh, suboptimal.
Traditional system package managers are also terrible. They install everything into the global /usr directory so that you can't have differing sets of depdencies for different software and they require root access because /usr is only writeable by root. Because of these severe limitations and without effort being put in to fix it, I think GNU/Linux distributions have helped push everyone towards using a new package manager per language so that people can get their work done.
The solution to all of these problems is functional package management. They take the good parts of both system and language-specific package managers and add even more features and improvements on top. Functional package managers can handle software written in any language, allow unprivileged package installation, and allow different packages to depend on different versions of the same software without issue. They have additional features such as transactional upgrades and rollbacks, and system-wide deduplication. The entire dependency graph is precisely captured, all the way down to a small set of bootstrap binaries that are the roots of the graph. The GNU Guix [0] and Nix[1] projects implement the functional package management paradigm, and they are both worth taking a serious look at. In addition to standard package management features, they also can do full-system configuration management with their respective distributions GuixSD and NixOS.
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?
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...
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.
