text: I am glad that you have started thinking about the module split. 1) Why are the distributions named in CamelCase? Why not 'distribute.resources' instead of 'DistributeResources' (like, for instance, zope.interface instead of ZopeInterface). 2) In your proposal below, version comparison is part of distribute.installer; this means distribute.resources (and other modules needing version comparison) will be depending on distribute.installer, correct? Is this intended, or should version comparison go to something like distribute.core? 3) PyPM's backend uses a) pkg_resources' version comparison, b) package_index's download logic (not API-friendly). I'd be interested to see distribute.installer provide this download logic (finding URLs, tarballs and fetching them) as an API. I believe pip and zc.buildout too relies on this download logic. 4) How about distribute.pypi that interfaces with pypi? -srid On Tue, 11 Aug 2009 15:30:47 -0700, Tarek Ziadé <ziade.tarek at gmail.com> wrote: > Hey, > > I've started to work on splitting Distribute into several distributions > for 0.7 > > Here's the organization I was thinking about: > > - Distribution - Content: setuptools package renamed to distribute (minus some > elements). root modules in setuptools will be moved to the > distribute.core package so the > root namespace stays empty. > > - Distribution - Content: the part of pkg_resources.py that handles installed > distribution querying + renamed to "distribute.resources" > > - Distribution - Content: the part of pkg_resources.py that handles entry points + > renamed to "distribute.entry_points" > > - Distribution - >