<p dir="ltr"><br>
On 26 Aug 2013 05:53, "PJ Eby" <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br>
><br>
> On Sun, Aug 25, 2013 at 12:58 PM, Jim Fulton <<a href="mailto:jim@zope.com">jim@zope.com</a>> wrote:<br>
> > On Sun, Aug 25, 2013 at 3:06 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> >> The clumsiness of the __main__.__requires__ workaround aside, the main<br>
> >> advantage this offers is that it *should* result in a relatively<br>
> >> straightforward addition to pkg_resources to make it work with wheel<br>
> >> files as well as eggs. That's important, because anyone that is<br>
> >> currently doing side-by-side multi-versioning in Python is using the<br>
> >> pkg_resources API to do it, since that's the only option currently<br>
> >> available.<br>
> ><br>
> > No. It isn't. Buildout doesn't use pks_resources to do it.<br>
> > (Buildout used pkg_resources at build time to manage package meta<br>
> > data, but I think that's orthogonal to what you're talking about.)<br>
> ><br>
> > I'd also hazard to guess that most of the folks with multi-version<br>
> > installs are using buildout to do it, as buildout does have a<br>
> > fair number of users.<br>
><br>
> FWIW, I would also note that if you use easy_install to install<br>
> anything, you are quite possibly using multi-version installs without<br>
> realizing it.  (The __main__.__requires__ API is used in<br>
> easy_install-generated script wrappers, so there isn't any way you'd<br>
> know about it without paying specific attention.)<br>
><br>
> I don't know how big the "buildout users w/known multi-version" vs.<br>
> "easy_install users w/implicit multi-version" groups are, but I<br>
> imagine the combined group has got to be pretty darn big.  ;-)</p>
<p dir="ltr">I'd be willing to bet the number of Linux installs relying on multi-version imports without the end user's knowledge trumps both :)</p>
<p dir="ltr">Anyway, I like Paul's suggestion of defining a specific runtime format for this, even if it's just "wheel layout plus a RECORD file". I'm currently thinking of using the ".dist" suffix, matching the existing egg vs egg-info naming convention. </p>

<p dir="ltr">The likely vehicle for defining it will be the next generation installation database format.</p>
<p dir="ltr">Cheers<br>
Nick.</p>