Re: Package organization - Why no top-level module?

The idea is that while archetypes might depend on things like transform
and validation those modules are Pythonic, having little to no binding
that would require even Zope. My goal was simply to collect useful
functionality under reasonable APIs. Hopefully that explains the
choices.

As for the archetypes package itself I have a tree that has been
completely reorganized, breaking modules into logical subdirs and so on.
The issue is one of migration due to some of the import changes. While
not wanting to feel trapped by the current layout it would be a PITA for
many people.

-Ben

On Sun, 2003-06-15 at 11:38, Jeff Kowalczyk wrote:
> Archetypes is getting really interesting, I'm looking forward to working
> with it in the coming months to do some of the things I currently look to
> Formulator for.
> 
> One question though: shouldn't the entire Archetypes system be arranged
> under a top-level module? APE adopted this approach as it grew in scope.
> 
> It would seem to have benefits for ease of single-command CVS checkout,
> single-command intallation, and reducing the number of top-level modules
> Zope Products/ which aren't standalone products (maybe I'm
> misunderstanding the role of ArchGenXML, generator, validation and
> transform here). Doing a reorg after 1.0 and once products have been
> written to the current layout would be much more painful.
> 
> Thanks.
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Archetypes-devel mailing list
> Archetypes-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/archetypes-devel

signature.asc
Description: This is a digitally signed message part