[Wheel-builders] Building Kivy for manylinux1

Michael Sarahan msarahan at gmail.com
Thu Mar 29 21:47:36 EDT 2018


Conda's approach to system level dependencies can be summarized by "package
all the things."  Essentially everything is available or could be available
as a package.  There are some fringe exceptions, like glibc (tied too
strongly to kernel) and X11 (again, tied to hardware optimization
tightly).  Otherwise, essentially everything can be (and many things are)
available as conda packages.  For system-level packages, the packages have
traditionally contained both shared objects and any headers required.  As a
result, you'll often see the same package dependency listed as a build-time
and a run-time dependency.  Conda-build has a pretty new feature called
"run_exports" where a system-level package can declare runtime dependencies
that it should "export" to other packages that use the system level package
at build time.  There's a better description at
https://conda.io/docs/user-guide/tasks/build-packages/define-metadata.html#export-runtime-requirements

Conda-forge is a little behind on taking advantage of all the new
conda-build features.  What I would expect to see in a kivy conda recipe
would be something like:

requirements:
  build:
    - sdl2_package_name
  run:
    - sdl2_package_name

My best thought for comparison with wheels is that a large collection of
conda packages is more work to get started (building the system-level
dependencies as packages, vs. just using existing system level libraries
from apt or yum and statically linking against them), but once a good
collection of conda packages is established, the dependency solver makes it
easier than wheels to keep track of package compatibility needs and
boundaries.  Conda-forge especially has so many useful low-level libraries
that it is a compelling platform.

On Thu, Mar 29, 2018 at 4:29 PM, Dominik Lang <langdominik at protonmail.com>
wrote:

> Thanks, that already helped a lot. I did not know about that PEP.
> So CentOS 6 it is for sure.
>
> I'll have a look at all of these in time, I'd say, and maybe even expand on
> that dockcross image.
>
> One question regarding conda: How are the OS dependencies handled?
>
> I've looked through the scripts and might've missed it.  AFAIU so far,
> SDL2 determines the dependencies both at build- and at runtime.  Which
> makes it relatively easy to get a build, but if they're not there
> initally, they won't be available later.
>
> Thanks again,
>
> Dominik
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On 29 March 2018 5:53 PM, Michael Sarahan <msarahan at gmail.com> wrote:
>
> > Take a look at https://www.python.org/dev/peps/pep-0571/
> >
> > There's also conda-build, which is currently targeting CentOS 6 for the
> ecosystem.  Full disclosure: I work for Anaconda, and I'm the maintainer of
> conda-build.  I know that there has been some effort toward's Kivy's
> dependencies (SDL2 and such) on conda-forge, which is the largest community
> effort on conda packaging.  https://conda-forge.org/ and
> https://github.com/conda-forge/staged-recipes/search?q=
> sdl2&type=Issues&utf8=%E2%9C%93
> >
> > FWIW, many vendors do not fully adhere to the manylinux1 standard, so if
> you released noncompliant wheels, you at least would be in good company.
> It is better to stick to it, but it really isn't always feasible or easy.
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On 29 March 2018 5:57 PM, Jean-Christophe Fillion-Robin <
> jchris.fillionr at kitware.com> wrote:
>
> > Hi Dominik,
> >
> > I think the manylinx2010 image (that will be based on Centos6) should
> help:
> >
> > https://www.python.org/dev/peps/pep-0571/
> >
> > https://github.com/pypa/manylinux/pull/152
> >
> > Also to help create derive image, you could base yours on
> dockcross/manylinux-x64 (that itself derive from the manylinux one but
> include convenience tooling to build project)
> >
> > and read  how you can extend it.
> >
> > Hth
> >
> > Jc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/wheel-builders/attachments/20180329/c9ef4703/attachment.html>


More information about the Wheel-builders mailing list