[pycrypto] Need your input: Major modernization; dropping legacy Python support?
sebastian+lists at ramacher.at
Sat Feb 22 12:50:50 PST 2014
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 ( for the upstream bug,  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
> >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.
> > https://bitbucket.org/cffi/cffi/issue/109/enable-sane-packaging-for-cffi
> > 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the pycrypto