1 |
Hi, |
2 |
|
3 |
So here's a quick summary of what I've established so far about |
4 |
pycrypto/pycryptodome. |
5 |
|
6 |
pycrypto is abandoned and dead since 2013. It was forked into |
7 |
pycryptodome which is now maintained. The fork is partially compatible |
8 |
with pycrypto -- though some APIs were removed/replaced. From my quick |
9 |
experiments, every second random package I tried worked ;-). |
10 |
|
11 |
Now, pycryptodome has two modes of install. When it's installed as |
12 |
'pycryptodome' it installs 'Crypto' Python package -- which is the same |
13 |
name as pycrypto used, and is therefore more compatible with packages |
14 |
using the latter. There is also the alternative 'pycryptodomex' mode |
15 |
which uses 'CryptoDome' namespace and does not collide with pycrypto. |
16 |
|
17 |
For an initial attempt, I've added dev-python/pycryptodome using |
18 |
the former mode since it was required by a revdep. But it also means |
19 |
that it blocks pycrypto, and therefore we need to start looking into |
20 |
adding compatibility with pycryptodome into more packages. |
21 |
|
22 |
The problem is, as usual, setuptools/pkg_resources magic. Because even |
23 |
if a particular app uses APIs that are compatible between the two |
24 |
packages, pkg_resources will reject to run an app that specifies |
25 |
'pycrypto' as a dependency if pycryptodome is installed, and the other |
26 |
way around. From a quick look at the specification, those dependency |
27 |
specs don't really support any kind of any-of. |
28 |
|
29 |
That is, I think it is reasonable to assume that the only way forward |
30 |
upstream would be to replace the dependency with 'pycryptodome', |
31 |
and start requiring the latter. |
32 |
|
33 |
As for Gentoo, I think the sanest way forward would be to live with |
34 |
that. Start testing packages with pycryptodome. If they don't use |
35 |
pkg_resources and API compatibility can be achieved, add || ( |
36 |
pycryptodome[...] pycrypto[...] ) if supported. If that is not possible, |
37 |
a revbump switching to pycryptodome would be reasonable. |
38 |
|
39 |
After all, we don't really have many revdeps [1] to port. |
40 |
|
41 |
Any other ideas? |
42 |
|
43 |
[1]:https://qa-reports.gentoo.org/output/genrdeps/rindex/dev-python/pycrypto |
44 |
|
45 |
-- |
46 |
Best regards, |
47 |
Michał Górny |