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

[David Bolen]

On 9/13/07, Paul Moore <p.f.moore at gmail.com> wrote:
> On 13/09/2007, David Bolen <db3l.net at gmail.com> wrote:

> > 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.

That's a fair point - my comments are all related to the standard
Python distribution and building extensions with the VS.NET compiler
(including the binary installer I had built for Bill).

> 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.

If we're talking about the construction of binary Windows installers,
I'd just suggest that they get built as the built-in SSL module does,
including the static linking with a pure Windows OpenSSL build, which
is a bit simpler for the typical end user and has no other external
requirements.

Of course, that certainly doesn't stop a person who has already set up
their system for using mingw for extensions from doing their own
compilation, although it does raise a question as to whether the
setup.py would need some further adjustments to cover that case most
cleanly.

-- David