[Python-Dev] Windows package for new SSL package?

[Paul Moore]

On 13/09/2007, David Bolen <db3l.net at gmail.com> wrote:
> Bill Janssen <janssen at parc.com> writes:
>
> > In that case, I think your idea of just hard-coding a path is probably
> > the right thing to do.  I'll add a note that this is how you need to do
> > it if you are going to try "python setup.py build".  Presumably the
> > binary then built with "python setup.py bdist" will install on a Windows
> > machine regardless of where OpenSSL is installed?
>
> Yes (though typically bdist_wininst for the Windows installer), but
> perhaps not for the reason you think.
>
> I think where there's probably a small disconnect here is that, there
> really isn't an OpenSSL "installed" on the end user's machine.  Well,
> there could be, but Python isn't using it.  The OpenSSL library is
> statically linked as part of the _ssl.pyd module, as it will be with
> your _ssl2.pyd module.  (That's also why there is no OpenSSL to "find"
> in your setup even with Python installed - at least not any libraries
> you can use).

That's not 100% true, is it? If I use mingw and Gnuwin32 openssl, I
believe the default is a dynamic link of openssl (it depends on the
import library used, and gnuwin32 supplies dynamic libs by default).
So the openssl DLLs need to be on the user's PATH for the extension
module to work.

> In other words, both the standard and your extension module on Windows
> bring along their own OpenSSL.

For the extension, you may need to (1) document that the user needs to
have the openssl DLLs on their PATH and possibly (1a) supply a zipfile
with the necessary DLLs as a supplemental download, or (2) arrange for
the openssl DLLs to be included in the extension installer, and
installed alongside the .pyd file.

Alternatively, it *may* be possible with setup.py magic to force a
static openssl link (but would that need hard coding for the gnuwin32
naming conventions?)

Paul.