On Thu, Nov 3, 2016 at 3:02 PM, Paul Moore <p.f.mo...@gmail.com> wrote:
> it may be possible to define a > >> standard approach that goes something along the lines of defining a > >> standard location that (somehow) gets added to the load path, and > >> interested parties provide DLLs for external dependencies, which the > >> users can then manually place in those locations. > > > > that't pretty much what conda is :-) > > Well, it doesn't feel like that. Maybe we're not understanding each > other. Am I able to take a non-conda installation of Python, no -- not at all -- but there is no "system install" of Python on Windows that your IT folks are telling you that you shoudl use. (except maybe IBM, if I recall from a David Beazley talk) So conda provides that as well. But anyway, I meant _conceptually_ it's the same thing. use conda > to install *just* a set of non-Python DLLs (libxml, libyaml, ...) and > then use pip to install wheels for lxml, pyyaml, etc? If you have a conda python already, then yes, you can install conda packages of various libs, and then build pyton packages that depend on them. And now that I think about it -- you could probably: install conda (which WILL install python -- cond needs it itself...) do some munging of environment variables. Use another python install to build wheels, etc. If you got your environment variables set up right -- then building from anywhere should be able to find the conda stuff. But I don't know that you'd get any of the advantages of conda environments this way. I'm still trying to figure out why you'd want to do that on Windows, though -- why not let conda manage your python too? that there currently isn't a way to *build* an lxml wheel that links > to a conda-installed libxml, but that's not the point I'm making - if > conda provided a way to manage external DLLs only, then it would be > possible in theory to contribute a setup.py fix to a project like lxml > that detected and linked to a conda-installed libxml. That single > source could then be used to build *both* wheels and conda packages, > avoiding the current situation where effort on getting lxml to build > is duplicated, once for conda and once for wheel. see above -- conda is putting dlls into a standard place -- no reason you couldn't teach other systems to find them. In fact, I did something like this on OS-X a long while back. There was a project (still is!) called "Unix Compatibility Frameworks": http://www.kyngchaos.com/software/frameworks It has a bunch of the dependencies needed for various python packages I wanted to support (matplotlib, PIL, gdal...). So I installed that, then build bdist_mpgks against it (no wheel back then!). I distributed those packages. In the install instructions, I told folks to go install the "Unix Compatibility Frameworks", and then all my packages would work. Similar concept. However, one "trick' here is multiple dependency versions. A given conda environment can have only one version of a package. If you need different version, you use different packages. but that would get ugly if you wanted your external wheels to link to a particular package. This all gets easier if you manage the whole stack with one tool -- that's why conda is built that way. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
