Bento, a pythonic packaging solution for Python software

Really? They're completely unrelated products. I don't see any problem with the name.

I wished I could have taken exactly the same format, but unfortunately, the cabal format was not defined (no formal grammar) when I started this, and I needed reST support for some fields, which makes it a bit difficult. This also explains why the format is not exactly YAML.

I don't mind things having their own packaging solutions, because it does get over a hurdle of trying to use things that have broken or non-existent package management systems (I'm looking at you Windows and OSX). What I do mind is when there's not an obvious way to work with the language's provided packaging system to make rpms or debs. Or the language's packaging system actively works against other packaging systems because it's, uh, "unpythonic" or it's just not way it's done in our environment because we're special. The whole idea of a "this is a pythonic packaging system" seems to say "all other previous packaging systems python has used have been unpythonic", which wasn't the case when the previous packaging systems were released -- everyone claims theirs is the best. It's good to have the ability to install things without the system packager (say, in another directory for testing or development purposes), but when it comes time to productionize something, the language's library management needs to work with the system packager.

I think ruby is especially bad in this regard. There's some mindset that seems to say everything should be manageable as if it was a gem, even if it wasn't installed via gem. gem seems to be used to manage dependencies within the library itself, which breaks if the library itself isn't managed with gem. So you sometimes need to fake it (admittedly, I have not installed ruby libs in a while, but I had to make http://github.com/thwarted/gem2deb to make this mildly more manageable, but that's still only a 90% solution and that last 10% is particularly annoying).

perl is an example of one that gets it close. In most cases, you can do the build and stop before the install. Then the contents of the blib directory are the entire contents that needs to be installed, so you can just package that up -- this makes it compatible with all popular system packaging systems. And even then, we have cpan2rpm that does the heavy lifting of scripting finding the package on CPAN.

Package management is pretty much a solved problem, and it's solved for the general case of putting files in place and asserting (and resolving) dependencies -- assuming all the dependencies are packagable/available in packages (which is easy to achieve if things can be easily packaged). If you think you need more than that, it might be time to revisit how your libraries are written and how your language uses libraries. If it's anything more than "are the files in a place where the language can find them", it may be time to revisit it.

Because deb and rpm repos lag behind releases, install packages globally, and don't lend themselves to portability. Setting up a private deb repository is still prohibitively complex even for those of us who only target one platform and architecture (at least last I checked).

Why we as a Python community need Bento is another question. In my mind distribute, pip, and virtualenv combine to create a simple, robust, portable packaging, building, and installation system that I have been very happy with. Dependencies are automatically resolved, environments are self-contained, and portability/backup is a copy command away.

I love aptitude for installation of global dependencies; beyond that I've never found a use for it.

There are significantly more package managers than apt and rpm. If languages each have their own package manager and library installer, it's only one thing for the writer of the library to deal with.

If it was left up to the OS's package manager the writer would have to maintain 10 to 15 different packages, or get other people to. Would you rather deal with one gem, or bento package or one each of whatever rpm/apt/yum/pacman/brew/macports/pkgsrc/... use?

If different OSs all converge to one package manager in the near future, then, great! we can use that. Until then though, I think language specific ones are just fine.

You mean .deb or .rpm, apt is a distribution/update tool. The Linux market is fractured enough in this respect, and better not start talking about Mac or Windows, where you can't even properly integrate into a baseline packaging system (because there is none).

I think as soon as the major OS suppliers agree on a common packaging/distribution technology, you'll see the language formats vanish. But as long as that doesn't happen, there's no really good alternative to CPAN/gems/eggs etc.

Why you'd need multiple formats for one single language is a bit beyond me. Especially in Python, which traditionally abhors Tim Toady.

(I am the bento author)

Let me first note that I love the apt system - I think it is a great system. And one of the rationale for bento is to make debian (and linux) packaging easier. Bento supports the same options as autoconf for integration with systems, and I want to make python build solutions more hackable in general.

Nevertheless, apt has several issues: - it does not work on non-apt systems. Simply put, the majority of the scipy community does not use a deb system. - it does not allow for non-root installation, at least in practice - it forces you to follow upstream dev cycles.

I don't think you should use just now (it is marked as experimental quick clearly :) ). As for the advantages: - support for arbitrary installation scheme, like autoconf (e.g. you don't have to hardcode installation path to install data as with distutils) - data files are easier to deal with - even though it is really raw, the internal tool to build C extensions has automatic dependency handling, md5-based coutent change detection, and supports parallel builds. - it is designed to be hackable. I want to be able to use scons or waf to build complex extensions (I am coming from numpy/scipy, which has particularly strong needs for building C extensions compared to the average python library)