[pycrypto] Need your input: Major modernization; dropping legacy Python support?

[Sebastian Ramacher]

Hi

On 2013-10-29 23:09:24, Dwayne Litzenberger wrote:
> 1. How many of you would really care if PyCrypto 2.6 was that last
> version to support legacy versions of Python?  By "legacy", I mean
> all versions of Python that are NOT one of these:
> 
>     - Python 2.6.x
>     - Python 2.7.x
>     - Python 3.3 and above.
> 
>    I'd continue to make bugfix releases of PyCrypto 2.6.x, but add
> no    more substantial new features.

No objection from me here. As I understand it, Python 2.6 got it's last
release yesterday, so I wouldn't mind if Python 2.6 got dropped too.

> 2. I'm thinking of pulling in additional dependencies (e.g. cffi),
> requiring setuptools, and basically joining what the rest of the
> Python community is doing in 2013.
> 
> 3. What if src/*.c were removed, and any relevant C code moved into
> an    independent library, which could be loaded using cffi?  (This
> is    basically what we need to do to support PyPy properly.)

I wouldn't mind if the C code is moved into a library, however cffi
doesn't seem to be ready to be used in binary distributions without
resorting to hacks ([1] for the upstream bug, [2] for a very short
thread on debian-python). I'm told that this will be fixed in cffi at
some point.

I've always had a good experience with Cython. What do you thinkg about
that?

Anyway, as long as we are not starting to use ctypes, I'll be fine.
Depending on the timeframe of this change, I'd prefer PyCrypto to use
someting that does not require hacks in binary distributions. If cffi is
fixed until the change happens, I won't complain.

[1] https://bitbucket.org/cffi/cffi/issue/109/enable-sane-packaging-for-cffi
[2] https://lists.debian.org/debian-python/2013/10/msg00070.html

> 4. What if Crypto.* became a wrapper around some other crypto library?

This depends on the crypto library you're thinking of. If it's openssl,
then all the GPL licensed reverse dependencies might have a problem (at
least in Debian).

> 5. The Apache License 2.0.  What if PyCrypto were licensed under it,
> or    included dependencies that are licensed under it?

With my Debian maintainer hat on, this would be a problem for me. We
still ship software that is GPL 2 only that depends on PyCrypto.
However, GPL 2 and the Apache License 2.0 are incompatible.

Examples of these packages include revelation and pymsnt (I stopped
searching for GPL 2 only reverse dependencies after I've found two).

Of course, if the license changes or python-crypto starts depending on
something licensed under Apache 2.0 this needs to be checked on a case by
case basis, but I'd rather avoid it if there is no really good reason to
do so.

Regards
-- 
Sebastian Ramacher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.dlitz.net/pipermail/pycrypto/attachments/20131030/85cca8a8/attachment.sig>