He is now employed by Apple.

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

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.

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

As others have pointed out system package management is quite different and solves an overlapping but distinctly different set of problems to programming language module package management. In particular system package management isn't cross platform whereas programming language module package management tries to be. The programming language module package management has to integrate with whatever system package management is doing.

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.

No one is suggesting using it as a system package manager, least of all Apple.

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.

I agree that language specific package managers are terrible. I'm one of those ops people, and the number of package managers needed to deploy any web application is just insane. The biggest problem is that none of them can specify the full dependency graph for anything. For example, the Pg Ruby gem cannot specify that it requires the libpq shared library and headers. You have to either know that before hand, or watch the package installation fail, find the right package in your system package manager, then try again. They are also bad at deduplicating dependencies amongst many projects, but at least they allow installation as an unprivileged user. How many more pm and vm (version manager) tools must we deal with? I wish more people would realize that this is a general problem that requires a general solution.

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.

[0] http://gnu.org/s/guix

[1] http://nixos.org/

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.

So you want every developer to produce rpm, deb, msi, depot, bff, pkg, dmg, <place missing package format here> taking into consideration OS specific paths and configuration settings for every single library, specially for packages common across OSes?!!

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

Already taken:

https://github.com/izqui/Taylor