Am 28.06.2010, 20:31 Uhr, schrieb Shane Hathaway <sh...@hathawaymix.org>:
> Around here, Python packages are how we communicate code. Think of a
> released package as a well-refined email. If you choose not to release
> packages, you are really choosing not to communicate through the
> established channels, so many people will not hear you. If you want the
> largest possible audience to hear you, you should release packages, just
> like you should use version control and bug trackers.
The communication failed for me. I don't want to be communicated code.
That's a technical detail I am not interested in. What I want to be
communicated is "which package is important? which package is reliable?
what's the standard solution?". The packaging system does not deal with
this level of information. It allows to download and install files in a
complicated way, that's all. The best I get is a "score" on PyPI.
So I've "heard" all the packages and their authors on why their package is
great. Just imagine what will happen if the moderate package count of < 50
zodb packages raises to 250. Do you want to listen to each one one of
these "communication packages" before actually getting started on your
Whereas a communication channel like this message list is much more
effective for this thing. E.g. Laurence told me Standalone ZCatalog is
basically a left over from older days. I can get a vague impression of
this of the last release date on the package page, but I still don't know
about the "new" or the standard solution. Just give me the bread, don't
make me figure out which flour there is and which kind of flour I need.
A standard library signals "This is the preferred way to do it. Look here
if you need reliable stuff. This is the standard solution.". I'll trust it
and take it. If I want to contribute something I'll contribute it to the
standard library as I know my efforts are not in vain. My code is
compatible with other people's code using the standard library.
E.g. the C++ STL made communication between coders much easier, finally
everybody is using std::vector and friends so I can understand code at a
glance and don't have to delve into the peculiarities of how everybody
rolls his own vector, list or array class. This also increased
interoperability between libraries.
Btw, I use different vcs, bug trackers and also package my things. I just
highly prefer staying away from any "package system". Give me a single
file including everything, I'll install it and it will just work. Make me
resolve all the conflicts and dependency issues of a .rpm file and I might
get cranky :-)
> The packaging system works a lot better than you think it does. You owe
> it to yourself to learn Buildout, which solves the package versioning
> problem you ran into. In my experience, the ecosystem of packages we
> have now is actually a good deal better than the Python standard library.
I did not run into a package versioning problem. Different packages were
outright broken. The .eggs were missing some meta-files and installed dlls
into the wrong places on windows. The ratio of broken packages I
encountered is probably around 10%. But these 10% take up 90% of my time.
A lot of these problems could have been detected and resolved sooner if
the packages had more users. The more users, the less serious problems.
You get more users per package by not spreading users over similar
The current "healthy ecosystem" is neither healthy nor a system. It's a
pile of random packages with no semantic meaning. Some good in there, some
crap. Very hard for me to find my way through it. Not organized by
criteria I am interested in.
I do not gain a lot from buildout. Almost all recipes are geared towards
plone/zope/web development. Neither of which I am involved in. In fact I
have my own build system based on SCons which also use to build C++
libraries, docs and more.
ZODB is a general python object database with a much wider audience than
just plone. It suits desktop applications just as well as applications
you'd normally use twisted and pickle for. Forcing all those zope
dependencies like buildout on people does not add to the attractiveness of
ZODB for users outside zope. Having indices only in plone does also not
make sense. Many applications would benefit from keyword, field,
full-text, spatial, younameit indices. Yet extracting individual packages
from zope/plone is impossible due to the slew of dependencies. While I can
accept a dependency like zope.interface I don't accept a lot of the
others. It really prevents ZODB from living up to its full potential in
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org