Varac wrote...
> * Package name : yq
> Version : 2.1.2
> Upstream Author : Mike Farah <mikefarah@gmail.com>
> * URL : http://mikefarah.github.io/yq/
Hello everybody,
it's been a while ... bookworm freeze is getting closer, and I'd like to
find a solution for the current problems providing an "yq" program to
handle yaml documents.
To sum it up:
* This ITP originally was about an implementation in Go ("go", by
mikefarah)
Pros:
+ (Possibly) faster
+ The first one in this thread
* There is another implementation in pure Python ("python", by kislyuk)
Pros:
+ Simple
+ By design behaviour identical to jq
* The respective upstream are not willing to resolve the name clash
In the meantime, there is a new player around, called "fq"
<https://github.com/wader/fq>, a somewhat Swiss army knife wrt
supported formats. Written in Go as well, it is available in bookworm.
Backporting to bullseye is at least not trivial.
Now my main interest was to have something as /usr/bin/yq, not just for
me but for everybody.
Ideas:
1. Co-existence
Debian ships both variants but with different binary names like "yq-go",
"yq-python" or "yq-mikefarah" and "yq-kislyuk". Using Debian's
alternatives system, user can set their preferred variant.
Pros:
+ Provides all flavours
Cons:
- Maintainance overhead
- Users might be confused because /usr/bin/yq is not what they expect
(generic problem with alternatives)
2. Giving up the Go variant in favour of fq, ship only "python"
Assuming "go" and fq overlap a lot, one might argue there's little use
in providing both. So there would by "python" as the "yq" program for
the simple use cases, everybody else please refer to fq.
Pros:
+ Packaging "python" should be simple and backportable
Cons:
- Anything specific to "go" is not available.
3. (your idea here)
Thoughts?
Christoph
¹ Fun story, years ago I implemented a little brother of "python", a
simple Perl script that reads YAML and pipes it to jq. Not at all
proud of it, and I'll be happy to ditch it.
Attachment:
signature.asc
Description: PGP signature