[Distutils] Current Python packaging status (from my point of view)
chris.barker at noaa.gov
Thu Nov 3 18:36:40 EDT 2016
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.
> 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
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":
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.
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.
Christopher Barker, Ph.D.
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...
More information about the Distutils-SIG