
Bento, a pythonic packaging solution for Python software - fogus
http://cournape.github.com/Bento/
======
teilo
Now this was not a wise naming choice.

<http://www.filemaker.com/products/bento>

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

~~~
teilo
Yes, and Firebird the open source database is a completely different product
than Firebird the open source web browser. Nevertheless, Mozilla changed the
name to Firefox because both were software products.

------
Mathnerd314
It seems to borrow heavily from Cabal, the Haskell packaging system:
[http://cournape.github.com/Bento/html/faq.html#is-bento-
base...](http://cournape.github.com/Bento/html/faq.html#is-bento-based-on-
existing-tools)

It would be nice if they were in fact instances of the same format and not
just very similar.

~~~
cdavid
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.

------
zokier
I hate when every language wants to have their own packaging systems. Whats
wrong with apt/rpm?

~~~
tdavis
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.

~~~
justhamade
A private trivial deb repository is very easy to setup.
[http://wiki.debian.org/DebianRepository/HowTo/TrivialReposit...](http://wiki.debian.org/DebianRepository/HowTo/TrivialRepository)

------
mkramlich
anybody used it? any sense of whether it's better than alternatives?

~~~
cdavid
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)

