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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 < >> [email protected]> 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 >> > >
_______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
