[Distutils] Multi-version import support for wheel files

Donald Stufft donald at stufft.io
Sun Aug 25 09:24:34 CEST 2013

On Aug 25, 2013, at 3:06 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 25 August 2013 16:41, Donald Stufft <donald at stufft.io> wrote:
>> On Aug 25, 2013, at 1:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> [snip]
>> I'll look at this closer, my off the cuff response isn't good but before I
>> commit to a side I want to dig into how it actually works currently.
> The clumsiness of the __main__.__requires__ workaround aside, the main
> advantage this offers is that it *should* result in a relatively
> straightforward addition to pkg_resources to make it work with wheel
> files as well as eggs. That's important, because anyone that is
> currently doing side-by-side multi-versioning in Python is using the
> pkg_resources API to do it, since that's the only option currently
> available.
> If Fedora is going to switch completely to a wheel based build
> process, we need to be able to do it in a way that allows side-by-side
> imports through pkg_resources to continue to work.
> I'd previously considered writing a pkg_resources replacement that
> worked with wheels instead of eggs, but I've now realised that would
> be repeating one of the mistakes made with the distutils2 effort: just
> as we needed to account for the fact that a lot of people are
> currently building their projects with setuptools, we also need to
> account for the fact that anyone doing side-by-side imports is using
> pkg_resources.
> Cheers,
> Nick.
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

Yea I understand the motivations for it. The main thing i'm worried about
is codifying a solution that ends up being a misfeature instead of a feature.

This may be perfectly fine (hence why I want to dig into further having never
used it greatly before) but in general I think we should be conservative in
copying things over from the old way into the new way.  The new tools in
many ways are removing features that are less than optimal or overall a bad
idea and that's good. We don't need to copy over every single feature if
someone really depends on a feature we don't bring over they can continue
to use the existing tooling.

That being said I don't know for sure that this falls into that category which
is why I want to dig into it more.

Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130825/0e44f637/attachment.sig>

More information about the Distutils-SIG mailing list