On 16 May 2015 at 06:45, Chris Barker <chris.bar...@noaa.gov> wrote:
>> > Personally, I'm on the fence here -- I really want newbies to be able to
>> > simply "pip install" as many packages as possible and get a good result
>> > when
>> > they do it.
>>
>> Static linking gives that on Windows FWIW. (And maybe also on OSX?)
>> This is a key point, though - the goal shouldn't be "use dynamic
>> linking" but rather "make the user experience as easy as possible". It
>> may even be that the best approach (dynamic or static) differs
>> depending on platform.
>
>
> true -- though we also have another problem -- that static linking solution
> is actually a big pain for package maintainers -- building and linking the
> dependencies the right way is a pain -- and now everyone that uses a given
> lib has to figure out how to do it. Giving folks a dynamic lib they can use
> would mie it easier for tehm to build their packages -- a nice benifit
> there.
>
> Though it's a lot harder to provide a build environment than just the lib to
> link too .. I"m going to have to think more about that...
It seems to me that the end user doesn't really have a problem here
("pip install matplotlib" works fine for me using the existing wheel).
It's the package maintainers (who have to build the binaries) that
have the issue because everyone ends up doing the same work over and
over, building dependencies. So rather than trying to address the hard
problem of dynamic linking, maybe a simpler solution is to set up a
PyPI-like hosting solution for static libraries of C dependencies?
It could be as simple as a github project that contained a directory
for each dependency, with scripts to build Python-compatible static
libraries, and probably built .lib files for the supported
architectures. With a setuptools build plugin you could even just
specify your libraries in setup.py, and have the plugin download the
lib files automatically at build time. People add libraries to the
archive simply by posting pull requests. Maybe the project maintainer
maintains the actual binaries by running the builds separately and
publishing them separately, or maybe PRs include binaries - either way
would work (although having the maintainer do it ensures a certain
level of QA that the build process is reproducible).
It could even include libraries that people need for embedding, rather
than extensions (I recently needed a version of libxpm compatible with
Python 3.5, for building a Python-enabled vim, for example).
The msys2 projects provides something very similar to this at
https://github.com/Alexpux/MINGW-packages which is a repository of
build scripts for various packages.
Paul
PS The above is described as if it's single-platform, mostly because I
only tend to think about these issues from a Windows POV, but it
shouldn't be hard to extend it to multi-platform.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
