Lennart Regebro wrote:
> I'd like to throw a stick in the fire by taking up a completely
> different issue:
> The amount of top level modules and repositories. :-)
> if lovely.rating depends on schooltool.something, not only does this
> mean any usage of lovely.rating (which I imagine I would like to use)
> also needs one module form schooltool. In addition, we have whatever
> top level module I choose to use. That involves three different
> repositories, mine, zopes and schooltools, and three new toplevel
What's the problem with top level packages?
> If I then throw in more modules that have more external dependencies,
> this will quickly mushroom. For example, I'd like to use ratings and
> tags with zblog. That means I need to involve the codespeak repository
> as well, and zblog has it's own top level module. And then I want a
> discussion forum (I don't think one of those exists) which presumably
> would have another top level module, and maybe another repository, and
> maybe more dependencies.
I don't understand how this is a problem. The TurboGears guys use stuff
from all over the Cheeseshop, they don't seem to have a problem with this...
And like Bernd says, it's gonna be a lot less of an issue if and when
all these things are available as eggs, even if they're only development
eggs (IOW checkouts as eggs).
> So, what I'm saying is, that I would like to minimize the amount of
> top level domains,
Why? Top level packages are just names, hence the term "namespace
> and external repository dependecies in the zope repo.
Well documented dependencies are ok. I'd rather depend on something
external than track vendor imports, like we currently do with pytz and
Zope3-dev mailing list