On 10 July 2015 at 00:50, Antoine Pitrou <solip...@pitrou.net> wrote: > On Thu, 9 Jul 2015 23:50:30 +1000 > Nick Coghlan <ncogh...@gmail.com> wrote: >> >> As Donald notes, I think we're now in a good position to start making >> progress here, but the first step is going to be finding a way to >> ensure that *by default*, pip on Linux ignores wheel files published >> on PyPI, and requires that they be *whitelisted* in some fashion >> (whether individually or categorically). That way, we know we're not >> going to make the default user experience on Linux *worse* than the >> status quo while we're still experimenting with how we want the >> publication side of things to work. Debugging build time API >> compatibility errors can be hard enough, debugging runtime A*B*I >> compatibility errors is a nightmare even for seasoned support >> engineers. > > By the way, I think there's another possibility if the Python packaging > authority doesn't want to tackle this (admittedly delicate) problem: > issue a public statement that Anaconda is the preferred way of > installing Linux binary packages if they aren't provided (or the > version is too old) by their Linux distribution of choice.
We already provide a page specifically aimed at alerting folks to their prebuilt binary options for the scientific Python stack: https://packaging.python.org/en/latest/science.html In addition to referencing the upstream conda components, that also links through to http://www.scipy.org/install.html where Anaconda and Enthought Canopy are both mentioned. (Also Pyzo, which was a new one to me, and further introduced me to a couple of interesting projects: http://www.iep-project.org/index.html & its successor http://zoof.io/, which aims to take advantage of the Project Jupyter architecture to better support multiple language runtimes) > It would then give more authority to software developers if they want > to tell their users "don't use pip to install our code under Linux, use > conda". I'd personally phrase such suggestions more along the lines of "For annoying technical reasons that folks are looking to find ways to fix, if you don't want to build from source yourself, then you'll currently need to use a Python redistributor rather than using the upstream Python Package Index directly. We know the conda binaries are kept up to date, but there isn't anyone we're aware of currently ensuring that up to date versions of our packages are readily available through Linux system package managers." Along those lines, while it's my personal recommendation rather than PyPA's collective recommendation, some of the references in http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html for "Third Party Supported" upgrade paths may prove useful. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
