Log file Viewer

[02:59:44] <friendlydave> I'm creating my first python package, and I'm not sure how to handle including an external library.

[03:00:38] <friendlydave> Its a dynamic library that I'm accessing via ctypes. Should I include the library, or download it at install time?

[03:02:37] <glyph> friendlydave: neither of those options sound good

[03:02:46] <glyph> friendlydave: ideally you would include the library in your wheel, but not in your sdist

[03:03:11] <glyph> friendlydave: what exactly are you doing?

[03:03:26] <glyph> friendlydave: also you may want to consider using cffi rather than ctypes

[03:06:53] <glyph> friendlydave: the "right" way to do this (inasmuch as there is a "right" way, the community is very much in flux around stuff like this) is to distribute a python extension module while statically links your native library

[03:07:07] <glyph> friendlydave: with ctypes there's no compilation step so there's never an opportunity to statically link.

[03:08:36] <friendlydave> glyph: the native library is just a .dll, and ctypes has worked fine for me, but I'll take a look at cffi

[03:09:17] <glyph> friendlydave: is this for a proprietary library?

[03:10:15] <friendlydave> glyph: no, its an MIT library, cross platform, I haven't done anything on linux yet, but I plan to later

[03:12:10] <friendlydave> glyph: I'm still learning all the packaging vocab, but I'll make note to include the library in the wheel

[03:12:46] <glyph> friendlydave: the reason I suggest static linking / cffi as opposed to including the dll as a data file / ctypes is that if it's cross-platform the same linking recipe will work in multiple places

[03:13:04] <glyph> friendlydave: but there are different things you need to do to get a shared library to get compiled and get included and get loaded on OS X / Windows / Linux

[03:13:26] <glyph> friendlydave: not to mention the fact that if a linux distro wants to package your work, they're not going to want a binary copy of the .so, they need to rebuild from source

[03:14:30] <glyph> friendlydave: (also cffi has a lot more safety features than ctypes and much better error reporting, especially in the case where you need to work on different platforms with different word and pointer sizes)

[03:18:34] <friendlydave> glyph: all very good information and tips, thanks a bunch!

[03:19:03] <ngoldbaum> there's also conda the package manager, and the anaconda python distribution, which was invented for precisely this problem

[03:19:19] <ngoldbaum> (not that it's perfect)

[03:19:20] <friendlydave> glyph: I'll probably look at some other packages, see how they interface with libraries and such.

[03:20:33] <ngoldbaum> getting python to work with an arbitrary external C library is definitely not straightforward, can be done though

[03:20:52] <ngoldbaum> my solution is to find a python library that wraps the C library and then depend on the python wrapper library

[03:20:59] <ngoldbaum> of course that's not always available

[03:22:38] <friendlydave> ngoldbaum: my library is effectively the wrapper; it uses __getattr__ and getattr(clib, prefix+name) to make calls

[03:23:52] <friendlydave> thanks for your help both of you!

[11:05:57] <ionelmc> glyph: you can static link stuff with cffi?!

[11:08:23] <glyph> ionelmc: yes, this is how cryptography distributes OpenSSL on OS X.

[11:08:39] <glyph> ionelmc: it's...tricky

[11:08:44] <ionelmc> interesting

[11:08:49] <ionelmc> what does it do for windows?

[11:10:58] <glyph> ionelmc: same deal

[11:11:04] <glyph> ionelmc: different compiler options, of course :)

[11:11:18] <glyph> their cffi configuration is fascinating

[11:11:24] <glyph> however it is 4AM so probably past the time I should be talking about this

[16:31:45] <ngoldbaum> not sure if this is the right place... but does anyone know if it's possible to build python on OS X El Capitan with SSL support? It seems Apple has removed the OpenSSL headers from the 10.11 SDK, which python needed to build the _ssl module on previous versions of OS X

[16:31:57] <ngoldbaum> I'm trying to avoid compiling openssl myself...

[16:32:28] <ngoldbaum> and since this is for an installation script that bootstraps a python environment, I can't rely on there being a package manager

[17:09:22] <dstufft> ngoldbaum: I think you need to either add back in the headers or bring your own OpenSSL

[19:52:02] <ionelmc> dstufft: what package implements pep 440 version objects?

[19:56:46] <ionelmc> dstufft: packaging right?

[20:11:45] <ronny> ionelmc: i fi recall correct setuptools strictversions are