At 10:00 PM 4/15/2009 +0200, Tarek Ziadé wrote: >Now for the "base" or "core" package, what peoplethat uses setuptools >do most of the time: > >1- they use zc.buildout so they don't need a base package : they list >in a configuration files all packages needed > to build the application, and one of these package happen to have >the scripts to launch the application. > >2 - they have a "main" package that doesn't use the same namespace, >but uses setuptools instal_requires metadata > to include namespaced packages. It acts like zc.buildout in some ways. > >For example, you mentioned atomisator.* in your example, this app has >a main package called "Atomisator" (notice the upper A) >that uses strategy #2 I think that there is some confusion here. A "main" package or buildout that assembles a larger project from components is not the same thing as having a "base" package for a namespace package. A base or core package is one that is depended upon by most or all of the related projects. In other words, the dependencies are in the *opposite direction* from what you described above. To have a base package in setuptools, you would move the target code from the namespace package __init__.py to another module or subpackage within your namespace, then make all your other projects depend on the project containing that module or subpackage. And I explicitly excluded from my survey any packages that were following this strategy, on the assumption that they might consider switching to an __init__.py or __pkg__.py strategy if some version of PEP 382 were supported by setuptools, since they already have a "base" or "core" project -- in that case, they are only changing ONE of their packages' distribution metadata to adopt the new strategy, because the dependencies already exist. >So : >- having namespaces natively in Python is a big win (Namespaces are >one honking great idea -- let's do more of those!) >- being able to still write some code under the primary namespace is >something I (and lots of people) wish we could do > with setuptools, so it's a big win too. Yes, that's why I support Martin's proposal: it would allow setuptools to support this case in the future, and it would also allow improved startup times for installations with many setuptools-based namespace packages installed in flat form. (Contra MAL's claims of decreased performance: adopting Martin's proposal allows there to be *fewer* .pth files read at startup, because only .pkg files for an actually-imported package need to be read.)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4