<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span><p dir="ltr">This is the kind of direction we're also exploring for Fedora & EPEL: setting up a distro specific devpi instance so we can automatically publish distro compatible wheel files, as well as separating the distro level licencing and preliminary security review step from the step of repackaging in a language independent format. (I need to set up a curated PyPI mirror for work anyway, and since I work at Red Hat, and the Fedora community are open to the idea, we're working on it upstream rather than inside the firewall)</p></blockquote><div><br></div><div>Btw, I've been doing this at my company, that is maintaining separate wheel indexes per platform we need (in our case, cent5 and cent6).<br></div><div>One problem here is that it's possible for pip download caches to get "corrupted" with the wrong distributions (i.e. the incompatible ones), since the distributions are not distinguishable by name<br></div><div>Would Fedora really consider releasing a public service where there fedora release is not represented in the distribution name? or would you be wanting to get more tagging spec'd out in Wheel 2.0 first?<br><br></div><div>P.S.  In looking at the PEP425/427 specs again, I'm slightly confused about the "build tag".  It's barely covered, but I can imagine using that possibly to distinguish dists, assuming pip support was added, alhough it's supposed to start with a number, which doesn't seem to fit the use case we'd want.<br></div><div> <br></div></div><br></div></div>