On Thu, Nov 3, 2016 at 3:02 PM, Paul Moore <p.f.moore@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.Barker@noaa.gov