Tarek Ziadé a écrit :
On Wed, Oct 14, 2009 at 4:19 PM, kiorky <kiorky@cryptelium.net> wrote:
kiorky a écrit :
[]
This may be quite current even if it's not a good habit to have circular dependencies between distributions. Imagine that.
B(0.7) -> A(0.6). A(0.6) -> B(0.7).
Can i have the same namespace "ns" shared between the twice distributions with both the setuptools namespaces implementation (A) and the pkg_util's one (B)? "Have" mean that i can import ns in both distributions.
Not sur to follow this. Is that two different working sets ? Off course, no. Only two package i would have on sys.path as a time.
So, if: * I have old distributions with C code even not declaring they are relying on setuptools, installing with the 0.6 code automatically. * I have entry points and namespaces from 0.7 available to import in 0.6 and vice-versa.
I will see no more objections.
Another related thing, as i read the pep376 implementation, it may be good and easy to provide some wrappers to some setuptools very used objects like WorkingSet or Environment as similary code is already implemented to smoothly migrate existing code.
In Distribute 0.7.x we will provide new tools, and we won't try to provide backward compat.
Sad to hear as emulation is possible, at least with 0.6.
Projects that whish to use Distribute 0.7 features will have to switch to it I guess,
Hard switching will make people hesitate to switch or not and IMO more not. Providing backward compatibility which runs on populars case may give additional time to distribute newcomers to appreciate the new APIs and migrate their stuff.
so, depending on the project, it can use various strategy to migrate its code.
If the package maintainers can afford to think to those strategies. In the view of a new setuptools release (0.7), there will be three ways to have python packages installed, 2 or 3 ways (0.6, distribute, 0.7?) to have namespaces and/or entry points and incompatibilities at each level. Even if each package family live on its own without busing the others flavors, integration of all those packages will be a PITA. Add on this the burden to know each deployment thing.
Tarek
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF