[Wheel-builders] Building Kivy for manylinux1

[Michael Sarahan]

PS: I think it's worth mentioning that the main complaint I hear about
conda packages is that you need conda to install them, whereas with wheels,
you just install wherever wheels are installable (essentially everywhere,
including anaconda/miniconda installations).  That's compelling, especially
for the core project maintainers who have way more interesting things to do
than worry about packaging.  I still think the dependency solver in conda
helps prevent broken installations, but I can't argue that wheels make less
work for maintainers.  The best answer for your packaging might be both
wheels and conda packages.  Conda-build can use pip to build wheels and
conda-packages in one go, so if that's a route you're interested in, feel
free to contact me off-list, or on the conda-build issue tracker.  It's
still pretty primitive, but it is workable.

On Thu, Mar 29, 2018 at 8:47 PM, Michael Sarahan <msarahan at gmail.com> wrote:

> 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/e031efe7/attachment-0001.html>