Hello. pycryptodome is a continuation and extension of the old and unmaintained pycrypto. Some of pycryptodome features: - supports Python 2.4 or newer, all Python 3 versions and PyPy, - drop-in replacement for the old PyCrypto library, - supports a variety of crypto algorithms. Some of the modern python packages already require pycryptodome: bug 601374. Since the original pycrypto is getting old and pycryptodome can be a drop-in replacement it would be nice to have pycryptodome in tree. Please add pycryptodome to the tree and make it an alternative to the old pycrypto.
Created attachment 460080 [details] initial ebuild Attached is an ebuild that works. In the existence of a file named .separate_namespace in the setup.py dir, it installs compiles in a separate namespace instead of the same as pycrypto, making it possible for both to co-exist. I've tested it with streamlink-0.2.0 (not in tree) and it works. The correct path is probably to create a virtual/python-crypto package and make packages depend on it for a smooth transition for pycrypto to pycryptodome. This is just a initial ebuild that probably contains lots of errors, so if you're using it, do it at your own risk.
(In reply to Rodrigo Saboya from comment #1) > Attached is an ebuild that works. In the existence of a file named > .separate_namespace in the setup.py dir, it installs compiles in a separate > namespace instead of the same as pycrypto, making it possible for both to > co-exist. > > I've tested it with streamlink-0.2.0 (not in tree) and it works. The correct > path is probably to create a virtual/python-crypto package and make packages > depend on it for a smooth transition for pycrypto to pycryptodome. If you have pycryptodome in a separate namespace and pycrypto is installed, streamlink (and most likely everything else) uses pycrypto. Virtual is much needed here.
(In reply to Coacher from comment #2) > (In reply to Rodrigo Saboya from comment #1) > > Attached is an ebuild that works. In the existence of a file named > > .separate_namespace in the setup.py dir, it installs compiles in a separate > > namespace instead of the same as pycrypto, making it possible for both to > > co-exist. > > > > I've tested it with streamlink-0.2.0 (not in tree) and it works. The correct > > path is probably to create a virtual/python-crypto package and make packages > > depend on it for a smooth transition for pycrypto to pycryptodome. > If you have pycryptodome in a separate namespace and pycrypto is installed, > streamlink (and most likely everything else) uses pycrypto. Virtual is much > needed here. Streamlink 0.2.0 won't work without pycryptodome. I patched Streamlink to use the namespaced Cryptodome instead of Crypto to not mess with other RDEPS (which, in my system, is only ansible).
(In reply to Rodrigo Saboya from comment #3) > Streamlink 0.2.0 won't work without pycryptodome. It works fine without it here. setup.py requires it though. > I patched Streamlink to > use the namespaced Cryptodome instead of Crypto to not mess with other RDEPS > (which, in my system, is only ansible). Cool. It'd be nice if you'd submit your patch upstream.
(In reply to Coacher from comment #4) > (In reply to Rodrigo Saboya from comment #3) > > Streamlink 0.2.0 won't work without pycryptodome. > It works fine without it here. setup.py requires it though. > > > I patched Streamlink to > > use the namespaced Cryptodome instead of Crypto to not mess with other RDEPS > > (which, in my system, is only ansible). > Cool. It'd be nice if you'd submit your patch upstream. I don't believe the namespaced cryptodome is a path upstream would like to pursue. Cryptodome is a fork and drop-in replacement for pycrypto. And making optional isn't very clean either. I believe Streamlink is correct, my patch was for my own testing purposes only.
https://github.com/gentoo/gentoo/pull/2975
@Python, pycrypto is dead and buried, so I think it's time we do something about it. Considering that it has quite a few revdeps [1], I think switching to a maintained fork is a reasonable solution. The question is: whether do we want to add pycryptodome as separate package, and convert existing consumers to ||/virtual, or just put it as continuation of dev-python/pycrypto. [1]:https://qa-reports.gentoo.org/output/genrdeps/rindex/dev-python/pycrypto
(In reply to Michał Górny from comment #7) > The question is: whether do we want to add pycryptodome as separate package, > and convert existing consumers to ||/virtual, or just put it as continuation > of dev-python/pycrypto. It's listed under a separate project name on pypi, and installs pycryptodome-*.egg-info. I think we need to add it as a package separate from pycrypto.
commit 5079b5bcc0ab71b4bb5a228aede0b34bd9bbc710 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Wed Mar 1 08:46:17 2017 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Wed Mar 1 08:47:51 2017 dev-python/pycryptodome: Initial commit, #602022 Initial commit for dev-python/pycrypto fork and partially drop-in replacement. Let's start with a simple, separate package and see how it works out for us.
