[Zope3-dev] Re: Packaging

[Martijn Faassen]

Jim Fulton wrote:
> [Martijn wrote:]
> >What does this mean? If zope.products contains widely used objects, then
> >I'd rather see it introduced in the standard distribution. I can imagine
> >stripped down Zope 3 distributions for special purposes that wouldn't
> >include zope.products, but that'd be unusual, just like a stripped down
> >Python standard library is the unusual way to distribute it.
> 
> Let me put it this way. I want to encourage people to build add-ons and
> products and I want to provide them a means to avoid having their stuff
> constantly broken,  I don't want to, at this time, get bogged down by
> trying to figure out what will be in a distributions still some months
> out.
> 
> A few months from now, I think we could and should reevaluate this,

Okay, I'll try to remind you of that when it is time. :)

We should also warn people that instances of stuff in zope.app.products
can break at this point in the future.

We should then go through zope.app.products and decide what gets
to stay, and what goes to one of these:

  * zope 3 community repository. Some of us are getting together and plan to
    start hosting a subversion repository at some point in the coming months.
    This is a non zope.org/com project aiming at low entry barriers and
    building a community. A variety of projects could be in this repository.

  * a project's own repository hosted elsewhere. This is similar to what
    I'm (temporarily) doing with zopexml at the infrae CVS. I'll likely move
    that into the community repository when it's there.

  * (Possibly, if necessary) a zope.org run zope extensions directory. 
    But zope.app.products may be fine for that if the other community
    infrastructure is in place.

When such a move takes place, imports and zcml will need to be adjusted
one time, and the instances will break.

> >zope.products breaks the rule that nothing in zope should depend on
> >zope.app. In that sense the original 'zopeproducts' name is better. It
> >also is more similar to what any non-zope committer extender can do when
> >extending Zope: they don't have the ability to add a new package into the 
> >'zope' namespace; they can only add new python packages.
> 
> Right.  This is a compromise.  An alternative is to create zope.app.products
> and zope.app.examples. I avoided this because we also want to make the 
> hierarchy
> less deep.

> Opinions?

It's a longer import statement. The hiearchy can be as flat there as anywhere
else. I don't really care much one way or the other myself; it's just 4 
letters more to import from zope.app instead of zope.

Consistency of uncertain value versus 4 letters less. I dunno. :)

Regards,

Martijn