[pycrypto] Need your input: Major modernization; dropping legacy Python support?
dlitz at dlitz.net
Tue Oct 29 23:09:24 PDT 2013
I'm thinking about making some fairly drastic changes to PyCrypto
(compared to what's happened historically) and I'd like to know how
these would impact people:
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.
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.)
4. What if Crypto.* became a wrapper around some other crypto library?
5. The Apache License 2.0. What if PyCrypto were licensed under it, or
included dependencies that are licensed under it?
6. What if src/*.c was mostly replaced with mostly just went away.
Don't panic. These aren't concrete plans yet, but I'd like to know how
this might affect various downstream PyCrypto stakeholders, and problems
I might expect to encounter if I went in any of these directions.
Of particular concern is FOSS distributors packaging PyCrypto (e.g.
Linux distros, *BSD ports trees, MacPorts/HomeBrew, etc.), and anything
else that might impact a large number of downstream end-users.
I've been maintaining backward compatibility in order to protect
end-users from bugs introduced in downstream forks of PyCrypto, but
that's made it hard to generate interest in working on PyCrypto. From
what I can tell, there are currently several Python crypto libraries,
and none of them are particularly great (including PyCrypto).
I'm beginning to wonder how the risk of downstream forks compares to the
risks that users face when developers still don't have a highly-visible,
easy-to-use Python crypto API. It might be better to merge PyCrypto
with one or more other Python crypto libraries...
Anyway, I'd love to hear what people have to say on this topic.
Dwayne C. Litzenberger <dlitz at dlitz.net>
OpenPGP: 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7
More information about the pycrypto