[Twisted-Python] Progress report on splitting packages

[exarkun at divmod.com]

On Tue, 20 Apr 2004 11:53:29 -0400, Itamar Shtull-Trauring <itamar at itamarst.org> wrote:
>Three suggestions so far:
> 
> 1. Separate namespaces for each project.
> 
>   twisted.internet
>   conch

  Advantages:

    Easy on developers
    No distutils tricks required
  
  Disadvantages:

    Litters the top-level namespace
    Less uniquely named packages must be renamed

> 
> 2. Keep all projects and core under twisted.
> 
>   twisted.internet
>   twisted.conch
> 

  Advantages:

    Easy on users.
    Keeps the top-level namespace clean.
    Keeps Twisted projects conceptually tied together.
    
  Disadvantages:

    Distutils tricks required
    Missing projects confuse users ("importing twisted.conch failed?  But I have Twisted installed :(")


> 3. Separate namespace for projects, e.g. 't' or 'tmlabs' (Zope3 was
> considering using 'z', though it like it won't happen in the end -
> http://mail.zope.org/pipermail/zope3-dev/2004-April/010469.html)
> 
>   twisted.internet
>   t.conch or tmlabs.conch
> 

  Advantages:

    Keeps the top-level namespace clean.
    Keeps Twisted projects conceptually tied together.
  
  Disadvantages:

    May require distutils tricks.
    Missing projects confuse users, but probably less than in #2


  Amendments to the above advantage/disadvantage lists welcome.

  I mentioned "distutils tricks" a couple times.  So far I have heard both that distutils can and cannot do this.  I suspect that it can, but I would like to hear details on how this would work.  In particular, I would like to know whether "twisted.foo" would exist before the "foo" project was installed, and if it would, both what it would consist of and how it would be treated when twisted core is being upgraded after the "foo" project has been installed (can it cleanly avoid overwriting things?).


  I am not sure which of these I support yet, but I think I am leaning towards #3.

  Jp