On May 19, 2015 4:55 AM, "Paul Moore" <p.f.mo...@gmail.com> wrote: > > On 19 May 2015 at 00:25, Chris Barker <chris.bar...@noaa.gov> wrote: > > Pretty much, yes. conda provides a way to package up and manage arbitrary > > stuff -- in this case, that would be non-python dependencies -- i.e. shared > > libs. > > > > So you can say that my_python_package depends on this_c_lib, and as long as > > you, or someone else has made a conda package for this_c_lib, then all is > > well. > > > > But python, setuptools, pip, wheel, etc. don't have a way to handle that > > shared lib as a dependency -- no standard way where to put it, no way to > > package it as a wheel, etc. > > > > So the way to deal with this with wheels is to statically link everything. > > But that's not how conda pa cakges are built, so no way to leverage conda > > here. > > Thanks for the explanation. So, in effect, conda-as-a-platform defines > a (somewhat) incompatible platform for running Python, which can use > wheels just as python.org Python can, but which uses > conda-as-an-installer as its package manager (much like RPM or apt on > Unix).
A repeatable, reproducible environment (GH:conda/conda-env) that does not require a C compiler to be installed for deployment. > > The downside of this is that wheels built for conda (assuming that > it's OK to link with shared libs) are not compatible with python.org > builds (as those shared libs aren't available) and that difference > isn't reflected in the wheel ABI tags (and it's not particularly > clearly understood by the community, it seems). So publishing > conda-based wheels on PyPI would be a bad idea, because they wouldn't > work with python.org python (more precisely, only things that depend > on shared libs are affected, but the point remains). system-site-packages may very well be for a different version of the python interpreter and stdlib. > > > We need to remember what leveraging conda would buy us: > > > > conda doesn't actually make it any easier to build anything -- you need a > > platform-specific build script to build a conda package. meta.yaml (w/ optional preprocessing # [selectors]) http://conda.pydata.org/docs/build.html calls build.sh or build.bat by default, at build time. > > > > conda does provide a way to manage non-python dependencies -- but that > > doesn't buy you anything unless you are using conda to manage your system > > anyway. NodeJS, R, Perl (GH:conda/conda-recipes) > > > > conda DOES provide a community of people figuring out how to build complex > > packages, and building them, and putting them up for public dissemination. > > > > So the thing that leveraging conda can do is reduce the need for a lot of > > duplicated effort. And that effort is almost entirely about those third part > > libs -- after all, a compiled extension that has no dependencies is easy to > > build and put on PyPi. (OK, there is still a bit of duplicated effort in > > making the builds themselves on multiple platforms -- but with CI systems, > > that's not huge) PPAs would be great > > Agreed - that benefit would be significant (and not just in terms of > Python packaging - I'd personally find it useful in a lot of > non-Python projects), but it does rely on the information/scripts > being accessible in non-conda contexts. For example, for python.org > wheels, some way of modifying the build to create static libraries > rather than shared ones. I'm not sure to what extent the conda folks > would want to deal with handling the issues outside their own > environment, though (after all, working within a closed environment is > part of what makes the problem tractable for them). > > The whole area of collecting build processes for common libraries is > an area that's always been badly managed on Windows, probably because > no-one has ever looked at it in a wider context than their own > project, and also because every library has its own "building on > Windows" solution (configure, custom MSVC solution files, CMake, etc). > And also because C/C++ has no concept anything like PyPI. But while > this is hugely interesting to me, it's not clear how well it fits with > Python packaging and distutils-sig (except as an unresolved C/C++ > issue that we have to contend with). > > Paul > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
