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 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 _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev