homepage

Python has its own implementations of various hash functions, that can be used as fallbacks when openssl is not available. However, if openssl *is* available at build time, then these fallbacks don't get built.
It would be nice if they would get built even if openssl *was* found at build time:
 (1) for (perceived?) licensing issues, one might choose to run without linking with openssl (see http://mail.python.org/pipermail/python-dev/2011-March/109053.html; that message requests that a bug be opened about this, but I wasn't able to find it?)
 (2) for "portable" builds: build onto portable or shared storage, and run on multiple machines, even if openssl happens not to be available on some of the machines.

> that message requests that a bug be opened about this, but I wasn't able to find it?
Probably because no-one opened an issue.
> build onto portable or shared storage, and run on multiple machines,
> even if openssl happens not to be available on some of the machines.
For portable builds, I would suggest you ship OpenSSL as part of the build.

Actually, the modules are always compiled when in debug mode. Here is a patch to always compile them.

Thanks for the prompt response!
Yes, this looks good, I made a very similar patch myself and it seemed to work correctly (but that was on 2.7, and I didn't know how exactly to fix up the tests...).
Thanks again!

The official way for building certain modules despite auto-configuration is to edit Modules/Setup, or Modules/Setup.local. This already supports the exact use case, so I'm closing this as "works for me".

Antoine: why did you reopen it? Leave *at least* an explanation please.

> Antoine: why did you reopen it? Leave *at least* an explanation please.
Ah, sorry. I think it's a reasonable enhancement request, and
furthermore the patch simplifies the setup code. 
Also, it allows us to test the _md5 (etc.) modules in non-debug mode as
well. Perhaps Gregory can tell us what he thinks.

If it's an official feature that these modules are always built, the patch is insufficient: it then also needs to adjust the build environment for Windows, and the packaging. It potentially also affects packaging for OSX and Linux.
I still think that users with special needs such as (1) and (2) in the original message are better served by editig Modules/Setup, as that also allows e.g. to make the modules truly builtin.

I don't have a problem with always compiling them.
Distro packagers should see that the stand alone versions are not distributed with their package that has a dependency on openssl as they'll just be a waste of space. But that is up to the distro package maintainers.

I think (2) is very important, and I agree Gregory about the distro responsibility for size.
further more, if everything is define using the standard Modules/Setup, or Modules/Setup.local during compile/build time, why having a fallback anyhow in hashlib.py ?
BTW anyone that compiles for embedded systems adds a patch for remove all the code that detects modules automatically
see this from openembeded.org:
http://cgit.openembedded.org/openembedded/tree/recipes/python/python-2.6.6/nohostlibs.patch?id=9389f986ac8672cb671f00ab749ce323340b9500 

Python in Gentoo is also patched to always build _sha256, _sha512, _md5 and _sha1 modules.

regarding the attached patch, rather than changing the test at all, I'd leave it as is. The test as is will do what we want on the buildbots (warning us if they failed to compile when in debug mode). I am not concerned about it testing if they compiled in opt mode or not. I also do not think it is worth making them always compile on other platforms that do not use setup.py.
In short: if we do anything, just make the setup.py change to get rid of the conditional compilation.

New changeset 0a1d7be10946 by Antoine Pitrou in branch 'default':
Issue #14693: Under non-Windows platforms, hashlib's fallback modules are always compiled, even if OpenSSL is present at build time.
http://hg.python.org/cpython/rev/0a1d7be10946 

Ok, should be fixed now. I fixed the proposed patch to avoid warnings when testing under Windows.