[bug#53931] [PATCH] gnu: Add python-onlykey-solo-python

[bug#53931] [PATCH] gnu: Add python-onlykey-solo-python

[Pāladhammika via Guix-patches via]

[-- Attachment #1: Type: text/plain, Size: 28 bytes --]

All the best,
Pāladhammika

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-Add-python-onlykey-solo-python.patch --]
[-- Type: text/x-patch; name=0001-gnu-Add-python-onlykey-solo-python.patch, Size: 1602 bytes --]

From 372deb2998cf3c67ae59e89c629f7f5ab92d7015 Mon Sep 17 00:00:00 2001
From: paladhammika <paladhammika@protonmail.com>
Date: Thu, 10 Feb 2022 16:23:55 -0500
Subject: [PATCH] gnu: Add python-onlykey-solo-python

---
 gnu/packages/python-crypto.scm | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/gnu/packages/python-crypto.scm b/gnu/packages/python-crypto.scm
index e49ccdf1f2..23b52f1bce 100644
--- a/gnu/packages/python-crypto.scm
+++ b/gnu/packages/python-crypto.scm
@@ -1757,3 +1757,29 @@ (define-public python-sop
 scaffolding for the command line, which should make it relatively easy to
 supply a handful of python functions as methods to a class.")
     (license license:expat))) ; MIT license
+
+(define-public python-onlykey-solo-python
+  (package
+   (name "python-onlykey-solo-python")
+   (version "0.0.28")
+   (source
+    (origin
+     (method url-fetch)
+     (uri (pypi-uri "onlykey-solo-python" version))
+     (sha256
+      (base32 "1xj1rzz6pqdsy0p2cr1vas3nw0l0ysxq6ww1hgiyb0cfim5bkf1i"))))
+   (build-system python-build-system)
+   (arguments '(#:tests? #f))          ;no tests
+   (propagated-inputs
+    (list python-click
+          python-cryptography
+          python-ecdsa
+          python-fido2
+          python-intelhex
+          python-pyserial
+          python-pyusb
+          python-requests))
+   (home-page "https://github.com/trustcrypto/onlykey-solo-python")
+   (synopsis "Python library for OnlyKey with Solo FIDO2")
+   (description "Python library for OnlyKey with Solo FIDO2")
+   (license license:asl2.0)))
-- 
2.34.0

[bug#53931] [PATCH] gnu: Add python-onlykey-solo-python

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Pāladhammika via Guix-patches via schreef op do 10-02-2022 om 21:31
[+0000]:
> +   (home-page "https://github.com/trustcrypto/onlykey-solo-python")

Why not use the upstream <https://github.com/solokeys/solo-python> of
the fork? The latest commits are the same.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[bug#53931] [PATCH] gnu: Add python-onlykey-solo-python

[Pāladhammika via Guix-patches via]

Are they? The trustcrypto fork claims to be 12 commits ahead. Even still it makes sense to use the fork that by trustcrypto since they also produce the onlykey package, no?

All the best,
Pāladhammika

------- Original Message -------

On Saturday, February 12th, 2022 at 3:43 PM, Maxime Devos <maximedevos@telenet.be> wrote:

> Pāladhammika via Guix-patches via schreef op do 10-02-2022 om 21:31
>
> [+0000]:
>
> > +   (home-page "https://github.com/trustcrypto/onlykey-solo-python")
>
> Why not use the upstream https://github.com/solokeys/solo-python of
>
> the fork? The latest commits are the same.
>
> Greetings,
>
> Maxime.

[bug#53931] [PATCH] gnu: Add python-onlykey-solo-python

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

Pāladhammika schreef op za 12-02-2022 om 16:21 [+0000]:
Are they? The trustcrypto fork claims to be 12 commits ahead.
> Even still it makes sense to use the fork that by trustcrypto
> since they also produce the onlykey package, no?

AFAICT the fork is exactly the same as upstream, except with a slightly
different name, without any text in the README and with some
docstrings, warnings and error messages tweaked.

The only non-tweak commit appears to be
<https://github.com/trustcrypto/onlykey-solo-python/commit/1d4e03ac00a60286554f4a8f4f22bf892446788e>,
which seems a tiny change that should have been discussed upstream
(maybe it's as simple as recognising both pairs of vendor_id/product_id).

Also, no development seems to happen in the fork, development happens
upstream.  The fork does not appear to accept pull requests and there
is no option for submitting an issue, whereas upstream does, so it
seems that upstream has a much better community.

Considering all this, this does not appear to be a fork
in the sense that, say, XEmacs is a fork of Emacs.  Instead, it appears
to be pure branding -- and branding that will cause collisions in the profile
at that if both upstream and the trustcrypto-branded variant are installed
in the same profile, since the variant didn't change module names.

As such, I do not see a reason to prefer the branded variant over upstream,
and I would recommend not to, to prevent future problems (see profile
collisions), to reduce the number of packages that need to be updated
and to not cater to marketing.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]