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

[Sebastian Ramacher]

On 2014-02-06 09:51:39, Dwayne Litzenberger wrote:
> On Wed, Oct 30, 2013 at 06:24:48PM +0100, Sebastian Ramacher wrote:
> >>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
> 
> ctypes is definitely not on the list.
> 
> From what I understand, CFFI will only try to build binaries if
> they're not already found.  I think as long as packages that use
> CFFI include the appropriate rules in their `setup.py build_ext`
> process, it shouldn't be a problem.  (I'd certainly work with you to
> make sure the packaging isn't a nightmare.)

cffi 0.8 has been released in the meantime. I hope the issues have been
fixed, but I haven't had the time to check out the new version.

> >>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.
> 
> Ugh, GPL 2 only.  I wish people would at least do "or any later
> version".
> 
> I'm thinking of merging with the folks at https://cryptography.io/,
> which is covered by an Apache 2.0 license.

What is the merge going to look like?

> How bad is the situation with GPL2-only packages?

I'll check the reverse dependencies in a couple of days.

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