Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

[Varac]

Package: wnpp
Severity: wishlist

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

* Package name : yq
Version : 2.1.2
Upstream Author : Mike Farah <mike...@gmail.com>
* URL : http://mikefarah.github.io/yq/
* License : MIT License
Programming Lang: Go
Description : yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

Features

- - Deep read a yaml file with a given path
- - Update a yaml file given a path
- - Update a yaml file given a script file
- - Update creates any missing entries in the path on the fly
- - Create a yaml file given a deep path and value
- - Create a yaml file given a script file
- - Convert from json to yaml
- - Convert from yaml to json
- - Pipe data in by using '-'
- - Merge multiple yaml files where each additional file sets values for missing or null value keys.
- - Merge multiple yaml files and override previous values.
- - Merge multiple yaml files and append array values.
- - Supports multiple documents in a single yaml file

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEESvqqiCmYrIkee91NVGXnfnh27QQFAluRAZEQHHZhcmFjQHZh
cmFjLm5ldAAKCRBUZed+eHbtBAbrEADFL/vL3M+eUIneP2H5Hr5jvlJQgU2Wu0qW
BbK6VqyeTPqb0yTSOgeey2M4LDES88vym+UfAOp8m8gGD1dnRVdgK3ubKnEKNOvk
ef0WpNO8A8qVuPKKvANq50c49Rlsj8DUzEbcI0OJ+ryKvMrwYnFOirQUxLrQciWI
KPIsVOdt4ahY+YDSLPDOjgaqLG5+lhaDer2rLWQPTAUROd0ajRWbBPbKWJmB9Kem
fMqvUrpmv/ZWb8HdRFLEGn50mkRLHMgZcF8hLMi09lwkdBgwjpSlLYf5TuZLESlw
VuUWAKNwwtz8Wx4noaoGVKh4zYnZe/ealY89ixvol5BN12AZmG/cv3dOlaQfs75s
6JB6IkWbC1a6yIMI91+MixNuIFGHqE+YFbbDC5ahmFjlsOC/DDoL4JIRAMmG5mOK
pKRiRdkeo7f/Yz7kbK8odM0YpZfdtR+vTW/29ex0sdRNWavj88kA8jKKU9mtE/rD
jZUj/A2lKkhJAk4wojwR8RZESxWV5k1CSYfORLVGszQA8EONeS0FeUj+aRbnC8e2
RFq6diV0xTRB20UdvYXxXb5Eeg15tpfBMjjMXDkGqueliObsQIv2A7+jBK6hjpz9
phS2ZSjbQ+cszCbzzNJS9jTIcf7DH7ruzc489svnpU5Cet3ZGNGrMglkt1Ederfo
EDPAbyfkIw==
=jMuP
-----END PGP SIGNATURE-----

[ChangZhuo Chen]

Control: retitle -1 ITP: yq -- lightweight and portable command-line YAML processor


I can help to maintain it under go-team.

ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B

[Antoine Beaupré]

On 2018-09-06 12:29:37, Varac wrote:
> Package: wnpp
> Severity: wishlist
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> * Package name : yq
> Version : 2.1.2
> Upstream Author : Mike Farah <mike...@gmail.com>
> * URL : http://mikefarah.github.io/yq/
> * License : MIT License
> Programming Lang: Go
> Description : yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

Just for the record, there's also a Python implementation, also called
yq, which also handles XML:

https://yq.readthedocs.io/en/latest/

I think it's slightly more interesting because it does more than just
YAML.. But maybe the python one should be called "xq" (or "xyq"?)
instead. ;)

In any case, someone should probably let those upstreams know about the
naming conflict.

A.

--
Be who you are and say what you feel
Because those who mind don't matter
And those who matter don't mind.
- Dr. Seuss

[Antoine Beaupré]

On 2018-10-26 14:55:28, Antoine Beaupré wrote:
> In any case, someone should probably let those upstreams know about the
> naming conflict.

Done:

https://github.com/kislyuk/yq/issues/41
https://github.com/mikefarah/yq/issues/189

we'll see how that flies.

That said, how is packaging going? :)

A.

[Varac]

Quoting Antoine Beaupré (2018-10-26 20:59:04)

> On 2018-10-26 14:55:28, Antoine Beaupré wrote:
> > In any case, someone should probably let those upstreams know about the
> > naming conflict.
>
> Done:
>
> https://github.com/kislyuk/yq/issues/41
> https://github.com/mikefarah/yq/issues/189
>
> we'll see how that flies.

It didn't even take off - both authors seem to be unwilling to rename their
projects. I guess debian just needs to decide which name to pick.
The python implementation "was started before the other project was renamed to yq".

Anyhow, I'm fine with whatever name and whatever project.
@ChangZhuo: What's the state about packaging ?

greetings, varac

[rmescandon]

Hi guys,

I see this thread in ITP status. However, I wonder if this is still in
process of being packaged.

I've been maintaining the deb packages for such yq tool at my ppa
(https://launchpad.net/~rmescandon/+archive/ubuntu/ppa/) but I wanted to
step forward a little bit more by polishing and formatting everything
that is needed for having yq into the debian upstream.

Could it be possible for me to take this ITP thread and give it a go?

@ChangZhuo, @Varac: What do you think? Can I take the handover?

Thanks in advance

[Dominik George]

Hi,

> Hi guys,

Please try to be inclusive of other genders ☺. (Proposal: Hi folks; Hi people;
Hi friends,…)

>
> I see this thread in ITP status. However, I wonder if this is still in
> process of being packaged.
>
> I've been maintaining the deb packages for such yq tool at my ppa
> (https://launchpad.net/~rmescandon/+archive/ubuntu/ppa/) but I wanted to
> step forward a little bit more by polishing and formatting everything
> that is needed for having yq into the debian upstream.
>
> Could it be possible for me to take this ITP thread and give it a go?

I also jsut wanted to start work on a yq package for Debian. I think a month
later it is ok for you to setyourself as the owner of this ITP bug and take
over the packaging.

Please, if you start working, do so in a repository on salsa.debian.org. I
will happily mentor you and if that goes well sponsor your upload.

Cheers,
Nik

[Dominik George]

Hi,

> Hi guys,

Please try to be inclusive of other genders ☺. (Proposal: Hi folks; Hi people;
Hi friends,…)

>

> I see this thread in ITP status. However, I wonder if this is still in
> process of being packaged.
>
> I've been maintaining the deb packages for such yq tool at my ppa
> (https://launchpad.net/~rmescandon/+archive/ubuntu/ppa/) but I wanted to
> step forward a little bit more by polishing and formatting everything
> that is needed for having yq into the debian upstream.
>
> Could it be possible for me to take this ITP thread and give it a go?

[Roberto Mier Escandon]

Hi Dominik,

The word 'guys' is enough inclusive. See the second acceptation of https://www.wordreference.com/definition/guys. I've been using for a long time that greeting in environments of boys, girls or transexuals and I've never received a complain till reading your not fair mail answer. What is not inclusive is banning expressions. That thought manipulation leads to communism and sadly my country is at the gates of that due to general thoughts like that during years.

Related to the packaging, forget it. It is not too late, but after requesting the ITP I realized that golang 1.13 was needed along with some vendor dependencies which I'm not sure they will be available in the os when needed. (I know there were too much problematic dependencies, but my tiny mind does not remember the details now).

Sorry for the noise. I think I can continue exposing it in my ppa for now. If you give it a try to package and need some help, just let me know.

Cheers.

[Michael Banck]

Hi,

On Wed, Mar 25, 2020 at 09:00:13AM +0100, Roberto Mier Escandon wrote:
> The word 'guys' is enough inclusive.

https://twitter.com/AdamantxYves/status/1261222270393028609

Now can we get back to discussing packaging yq?


cheers,

Michael

[Roberto Mier]

Not really. Sorry, but yq releases use the newer Go versions that are not available in Debian distro. They are not available either as .deb most of the needed golang deps. It would be tough maintaining two versions of a package, because in any case the one I’m maintaining in my ppa is the one people want to use. So I prefer leave this responsibility to others.

Thanks.

> El 16 may 2020, a las 13:56, Michael Banck <mba...@gmx.net> escribió:
>
> Hi,

[Paride Legovini]

On Tue, 9 Jun 2020 Roberto Mier <rmesc...@gmail.com> wrote:
> Not really. Sorry, but yq releases use the newer Go versions that are not available in Debian distro. They are not available either as .deb most of the needed golang deps. It would be tough maintaining two versions of a package, because in any case the one I’m maintaining in my ppa is the one people want to use. So I prefer leave this responsibility to others.

Hi Roberto and others,

FYI I've been able to build the PPA version of yq 4.16.2 in a Debian
schroot just my bumping the golang-1.15 dependency to 1.18, and
adjusting d/rules GOVERSION accordingly.

Paride

[Christoph Biedl]

Varac wrote...

> * Package name : yq
> Version : 2.1.2
> Upstream Author : Mike Farah <mike...@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.

[Antoine Beaupré]

On 2023-01-15 21:02:17, Christoph Biedl wrote:

[...]

> 1. Co-existence [alternatives]

[...]

> 2. Giving up the Go variant in favour of fq, ship only "python"

[...]

I like that idea. I particularly like shipping the Python version since
(according to you) it's more faithful to the `jq` operation, which I
like.

I am biased though, having packaged more Python things than Golang (but
liking both languages, I guess...)

In either case, I would favor "whatever someone has worked on". I
signaled the existence of the Python one to avoid a *future* naming
conflict, but if no one is packaging *that* then maybe it's best to let
whoever actually did a package upload that and resolve issues later. :)

It's kind of unfortunate people can't agree on the internet though, but
I don't think it's something we should fix before closing this issue,
otherwise it's going to be a while...

a.
--
Either you're with us or you're with the terrorist state.