On 6 November 2016 at 14:44, Robert Collins <robe...@robertcollins.net> wrote:
> On 3 November 2016 at 22:10, Nathaniel Smith <n...@pobox.com> wrote:
> ...> dnf/apt/pacman/chocolatey/whatever and make my wheel work everywhere --
> and
>> that this will be an viable alternative to conda.
>
> As a distribution of sources, I think its very viable with the
> approach above: indeed we do similar things using bindep in OpenStack
> and that seems to be working out pretty well.
Right, and I guess we should also clearly distinguish between
"publisher provided binaries" and "redistributor provided binaries",
as I think a potentially good way to go long term for Linux might look
something like this:
* manylinuxN
A relatively narrow multi-distro ABI with updates driven mainly by
when old CentOS versions go EOL
We already have manylinux1, and it covers many cases, but not
everything (e.g. lxml would need to statically link libxml2, libxslt
and maybe a few other libraries to be manylinux1 compatible).
Most publishers aren't going to want to go beyond providing manylinux
binaries, since the combinatorial explosion of possibilities beyond
that point makes doing so impractical.
* linux_{arch}_{distro}_{version}
This is the scheme Nate Coraor adopted in order to migrate Galaxy
Project to using wheel files for binary caching:
https://docs.galaxyproject.org/en/master/admin/framework_dependencies.html#galaxy-pip-and-wheel
The really neat thing about that approach is that it's primarily local
config file driven:
https://docs.galaxyproject.org/en/master/admin/framework_dependencies.html#wheel-platform-compatibility
What that means is that if we decided to standardise that approach,
then conda could readily declare itself as a distinct platform in its
own right - wheels built with a conda Python install could get tagged
as conda wheels (since they might depend on external libraries from
the conda ecosystem), and folks running conda environments could
consume those wheels without needing to rebuild them. You'd also be
able to share a single wheelhouse between the system Python and conda
installs without inadvertently clobbering cached wheel files with
incompatible versions.
Being config file driven would also allow this to be extended to Mac
OS X and Windows fairly readily, where the platform ABI implicitly
defined by the python.org CPython binaries is even narrower than that
of manylinux1.
This scheme would mostly be useful in the near term for the way Galaxy
Project is using it: maintainers of a controlled environment using it
for managed caching of built artifacts that can then be installed with
pip.
However, it *might* eventually see use in another context as well:
redistributors using it to provide prebuilt venv-compatible wheel
files for their particular Python distribution.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
