[Distutils] the virtualenv-distribute mess

[kiorky]

Tarek Ziadé a écrit :
> On Wed, Oct 14, 2009 at 4:19 PM, kiorky <kiorky at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20091014/ee9190df/attachment.pgp>