[ZODB-Dev] SpatialIndex

[Nitro]

Am 28.06.2010, 20:31 Uhr, schrieb Shane Hathaway <shane at 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  
real work?

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

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  
non-plone applications.

-Matthias