On Sat, Apr 11, 2009 at 9:05 PM, Chris McDonough <chr...@plope.com> wrote:
> On 4/11/09 7:32 PM, Roger Ineichen wrote:
> >> That much dependency cleanup would be fantastic.
> > Yes, cool, but what exactly whould you like to cleanup?
> The bits that I use are already pretty nicely cleaned up. But in theory,
> if we
> did a more reasonable job of dependency management, I'd be able to use,
> zope.catalog without getting zope.publisher and ~30 other seemingly
> dependent packages sucked down too. That said, I've already created a
> catalog implementation (repoze.catalog) that requires only ZODB and
> so that particular example is not very useful to me personally.
> Maybe there are other pieces that could have a life outside of
> Zope-the-application-server. Or maybe not. Maybe they'll just die inside
> appserver. It's actually a heck of a lot easier to clean nothing up and
> continue to do what I've been doing, which is to fork every package that I
> useful so it can be used sanely outside an appserver context. That's been
> working out ok so far, and it feels better than needing to communicate on
> maillist in emails like this one. ;-)
> >> Heh. "Repoze" (unqualified with a suffix) is a whole
> >> separate thing; BFG obviously has its own naming issues.
> > I know that the spring turns many people crazy sometimes
> > but hey, we are developer and there a no girls arround ;-)
> > Let me know if the renaming excess is over and please
> > let me know with what I'm working and on what my
> > applications are running at that time.
> Hey, don't blame me, I didn't create the "Zope Framework/Toolkit" idea
> (personally I am not a fan of the concept). But it probably doesn't matter
> anyway. You needn't pay attention to any of this: nothing has changed at
> except for a bunch of names, and even those, not too much.
Rightly or wrongly, before the naming discussion came up, I was basically
already considering Repoze to be the Zope toolkit. Or Zope 4. The *stated*
goals for Zope Mega(tm) seem to align fairly closely with what Repoze
already is: extraction of the good, useful ideas from Zope into reusable
modules, refactored so as to avoid dependency hell. Some packages in the
zope.* namespace are already nice and reusable as is--I don't really care if
the tool of the moment starts with zope.* or repoze.*. If the trend were
merely to continue these sorts of refactors, call it Zope, or Repoze, or
whatever, you would find no complaint from me.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -