[Distutils] Current Python packaging status (from my point of view)

[Chris Barker]

On Thu, Nov 3, 2016 at 3:02 PM, Paul Moore <p.f.moore at 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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20161103/07c97056/attachment-0001.html>