On 30 Oct 2014 07:20, "Marcus Smith" <qwc...@gmail.com> wrote: > > yes, I'm partial to a solution like this prior to wheel 2.0 (that I imagine would support additional/custom tags)
+1 for being able to add additional custom platform tags in the file naming convention from me as well. As Marcus noted earlier, even if you set up distro specific indexes currently, there's nothing built into the tooling to keep you from trying to install (e.g.) a Fedora 21 wheel on RHEL or CentOS 5 (which is highly unlikely to work, given that the core ABIs in RHEL/CentOS 5 are 7 or 8 years old at this point). We'd be highly unlikely to flip the switch from "experimental service, use at your own risk" to "fully supported Fedora feature" while that's still the case. With arbitrary platform tags, we could inject that into the wheel filenames as part of the build process, and then again when invoking pip. That opens things up for us to figure out how to best flag compatibility on the distro side, without committing to a specific approach upstream (not yet, anyway). An alternative approach would be to add an "additional wheel suffix" setting for pip that allowed us to have names with endings like ".fc21.whl" or ".el7.whl" recognised as valid wheel files. I'm not that worried about the exact details though - the main feature I'd like is the ability to create wheel files that pip will ignore by default, but will accept if I specifically tell it what to look for. Cheers, Nick. > > On Wed, Oct 29, 2014 at 1:46 PM, Daniel Holth <dho...@gmail.com> wrote: >> >> I've always thought people might like to have a custom platform tag or >> otherwise customize the supported list in a configuration file loaded >> by pep425tags. Then you could create wheels called >> somewheel-4.0-py33-none-30caa8a209d6.whl (choose your own random >> string). Only a pip with a matching config would pay any attention to >> those wheels. That way we could help people manage their internal >> deployments without falsely advertising that we've solved the binary >> incompatibility feature baked into every Linux distribution. >> >> On Wed, Oct 29, 2014 at 3:52 PM, Donald Stufft <don...@stufft.io> wrote: >> > >> > On Oct 29, 2014, at 2:36 PM, Marcus Smith <qwc...@gmail.com> wrote: >> > >> > >> >> 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) >> > >> > >> > 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). >> > 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 >> > 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? >> > >> > 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. >> > >> > >> > _______________________________________________ >> > Distutils-SIG maillist - Distutils-SIG@python.org >> > https://mail.python.org/mailman/listinfo/distutils-sig >> > >> > >> > It’s a build number, it’s used incase you need to rebuild a Wheel using the >> > same source files. >> > >> > --- >> > Donald Stufft >> > PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >> > >> > >> > _______________________________________________ >> > Distutils-SIG maillist - Distutils-SIG@python.org >> > https://mail.python.org/mailman/listinfo/distutils-sig >> > > > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig