<div dir="ltr">yes, I'm partial to a solution like this prior to wheel 2.0 (that I imagine would support additional/custom tags)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 29, 2014 at 1:46 PM, Daniel Holth <span dir="ltr"><<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've always thought people might like to have a custom platform tag or<br>
otherwise customize the supported list in a configuration file loaded<br>
by pep425tags. Then you could create wheels called<br>
somewheel-4.0-py33-none-30caa8a209d6.whl (choose your own random<br>
string). Only a pip with a matching config would pay any attention to<br>
those wheels. That way we could help people manage their internal<br>
deployments without falsely advertising that we've solved the binary<br>
incompatibility feature baked into every Linux distribution.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Oct 29, 2014 at 3:52 PM, Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
> On Oct 29, 2014, at 2:36 PM, Marcus Smith <<a href="mailto:qwcode@gmail.com">qwcode@gmail.com</a>> wrote:<br>
><br>
><br>
>> This is the kind of direction we're also exploring for Fedora & EPEL:<br>
>> setting up a distro specific devpi instance so we can automatically publish<br>
>> distro compatible wheel files, as well as separating the distro level<br>
>> licencing and preliminary security review step from the step of repackaging<br>
>> in a language independent format. (I need to set up a curated PyPI mirror<br>
>> for work anyway, and since I work at Red Hat, and the Fedora community are<br>
>> open to the idea, we're working on it upstream rather than inside the<br>
>> firewall)<br>
><br>
><br>
> Btw, I've been doing this at my company, that is maintaining separate wheel<br>
> indexes per platform we need (in our case, cent5 and cent6).<br>
> One problem here is that it's possible for pip download caches to get<br>
> "corrupted" with the wrong distributions (i.e. the incompatible ones), since<br>
> the distributions are not distinguishable by name<br>
> Would Fedora really consider releasing a public service where there fedora<br>
> release is not represented in the distribution name? or would you be wanting<br>
> to get more tagging spec'd out in Wheel 2.0 first?<br>
><br>
> P.S.  In looking at the PEP425/427 specs again, I'm slightly confused about<br>
> the "build tag".  It's barely covered, but I can imagine using that possibly<br>
> to distinguish dists, assuming pip support was added, alhough it's supposed<br>
> to start with a number, which doesn't seem to fit the use case we'd want.<br>
><br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
><br>
><br>
> It’s a build number, it’s used incase you need to rebuild a Wheel using the<br>
> same source files.<br>
><br>
> ---<br>
> Donald Stufft<br>
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
><br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
><br>
</div></div></blockquote></div><br></div>