On Mon, 17 Sep 2018 at 17:08, Antoine Pitrou <anto...@python.org> wrote: > > Paul Moore wrote: > > I'm not really familiar with manylinux1, but I'd be concerned if we > > started getting bug reports on pip because we installed a library that > > claimed to be manylinux1 and was failing because it wasn't. (And yes, > > packaging errors like this are a common source of pip bug reports). > > > > It seems to me that it's defeating the purpose of having standards if > > people aren't willing to follow them... > > I agree with that. OTOH it seems providing binary wheels is generally a strong > demand from the community. I would be fine with only providing conda packages > myself.
I'm not going to argue conda vs wheels. As you've noted there's strong community interest in having wheels, but it's up to you whether you prefer to satisfy that interest or not. I will say that if there are problems with the existing standards that cause you issues in distributing your packages as wheels, then working with the community to address those issues with the standards is what I'd recommend. It's hard to see how anyone other than you could be better placed to explain the issues you face and propose solutions. On the other hand, no-one's forcing you to participate in the standards process, it's fine (as I said) if you prefer not to distribute manylinux1 wheels. What's not fine (IMO) is to effectively sabotage the standards process by distributing wheels that claim to conform to it but which actually don't. That makes life harder for everyone trying to make the standards work. I really appreciate the fact that you raised the question rather than simply doing so - once such wheels are published, it'd be hard to track what's going on, much less address the issue. > By the way other packages are already doing worse: > https://github.com/tensorflow/tensorflow/issues/8802 I know tensorflow have issues that the current standards don't really address. I believe they are discussing solutions in various places like the packaging issues and the wheel tracker. I wasn't aware that in the meantime they were distributing non-conformant wheels. That's not good, as you yourself state in https://github.com/tensorflow/tensorflow/issues/8802#issuecomment-401703703. FWIW, my understanding is that the libc restriction is to ensure compatibility with one of the older but supported RHEL versions (6?). I can appreciate that this might not be an important use case for some projects. Some final thoughts: 1. It sounds like manylinux2010 may be what you want. If you (the general "you" here - any project for which manylinux1 isn't sufficient) can't help move that effort forward, then you'll probably have to wait until those who can get it finalised. 2. Maybe there's value in a tag that emphasises "current hardware" more than backward compatibility? I don't know how such a thing could be usefully defined - it may not even be possible in any real sense - but that's a whole other standard proposal. Paul PS I'm assuming we're talking about publishing *on PyPI* - what people do on a private index is their own concern. -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/6JUC2NXF5IEMROK7RLIBKZ4ZEWOQWDN7/
