Hi Martijn, Yusei
I think there is a little confusion about which package depends on
Right now there is a zmi.core package this package should
contain core parts without to much dependency. After that
we need several zmi.* packages which are replacements for
each zope.app.* package. right?
I think it should be like:
1. zope.app.foo moves ZMI code to zmi.foo
2. zope.app.foo imports the zmi code from it's zmi.foo package
This allows us to move the zmi code from the zope.app packages
to zmi packages. Custom projects can then depend on zmi.foo
and skip the dependency to zope.app.foo. (at least for the zmi)
probably some zope.app.* packages contain only zmi code
probably some contain other code like Martijn told with
zope.app.form. That's fine and is not a part of our refactoring.
Projects which depend on zope.app.foo and will use the latest code
will get pulled in the zmi.foo package without any other dependecy
and should just work without to change the project setup since the
zope.app.foo package defines the zmi.foo dependency in thier
I think we should refactor the old menu implementaiton too
ar at least review it since this part is very, very slow.
But that's another part and could probably done after
finishing the zmi refactoring part.
> Betreff: Re: [Zope-dev] People in the "Zope 3" and "ZMI" teams
> Yusei TAHARA wrote:
> >> Should the old zope.app.* package depend on the new
> zmi.core package?
> >> (I think not)
> > No. But zmi.core might depend on zope.app.* packages.
> I think this should be avoided if we can. The idea is to lose
> the dependency of the zope.app.* packages for the ZMI, after all.
> Of course there are exceptions: if you rely on a zope.app.*
> package that hasn't really been moved to zope.* yet
> (zope.app.form.browser for instance). But relying on
> zope.app.*.browser should be avoided in most cases, otherwise
> we create circular dependencies.
> >> Or should we break BBB and let people know that they have
> to install
> >> zmi.core for zmi support? (I think so)
> > I won't break BBB as much as possible, at least I'd like to
> keep persistent data compatibility...
> But the ZMI is all views, right? What is persistent?
> For BBB, you want the zope.app.*.browser packages to import
> from zmi.core, not the other way around. Otherwise we don't
> clean up dependencies at all.
> >> - bump up the zope.app.* package version (full not partial)
> >> e.g. 3.5.1 to 3.6.0
> > Hmm, I'm not sure yet...
> I think this should be done; if you update a zope.app.*
> package to import its ZMI stuff from zmi.* a new release of
> the zope.app.* package should eventually be made, and it
> should have a new feature release (so increase y in x.y.z).
> > For now, I don't have clear image yet. I'm checking all zope.app.*
> > packages and make sure all tests pass. And maybe I will
> review current package dependencies.
> For that, you might want to investigate the
> z3c.recipe.depgraph recipe to generate dependency graphs. To
> try it against trunks you need to add them to 'develop' in
> your buildout.cfg
> > After that, I will copy zmi parts to zmi.core one by one. I'm sorry
> > but I'm very slow for some reasons, I cannot make an exact
> schedule yet.
> I don't think you're slow at all. Your plan sounds good and
> I'm glad you have Roger giving you feedback.
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! ** (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -