https://bugzilla.redhat.com/show_bug.cgi?id=2263790 --- Comment #42 from Petr Menšík <pemensik@xxxxxxxxxx> --- (In reply to Cristian Le from comment #36) > I only have some minor random comments: > - how will `%{_sbindir}/alternatives` work w.r.t. sbin/bin merger. > - from what I can see xq-golang is similar with the `xq` provided here, so > it should do the same Conflicts/Alternatives Well, yes. They would still conflict before I removed them, xq should have the same explicit conflict as yq had. > I can go either way w.r.t. Conflicts vs Alternatives. And I guess the main > thing we should do here is to discuss which one to go for: > > Ultimately these tools have completely different approaches, where python-yq > calls `jq` internally, while golang ones are completely self-contained, but > I don't think that is evident enough for the user to make a decision on > which version to go with. > > Personally I would choose the python version since it seems to be just a > thin wrapper against the python "standard" libraries (ignoring the question > of which yaml library is used), so I can see this as more stable, but then > the golang parsers can potentially be faster. > > If it was possible to add some description about each alternatives, I would > vote for Alternatives, but right now I am split between these two options. I have not tried any serious comparison. yqp will default to json output always. yq tries to autodetect input format and output in the same format if possible. Neither has manual page describing it. Which is a bit sad, because syntax is not trivial. At least for jq, the filter could be somehow rich. man jq provides better experience in console than reading examples from markdown. yq can do modifications by -i or '=' symbol. yqp is just reader, I think. I do not know advanced usage in jq filter. Probably could do even better, but not sure how. https://jqlang.org/manual/ is awesome resource to start. jq is quite powerful and well documented. > Can someone also play the devil's advocate for the Conflicts case? Right now there is no conflict, because I have renamed conflicting names. I am not sure having subpackage conflicting with yq and xq makes sense. Whether just symlink or alternatives usage. For common usage simple alias in shell would make it customizable enough IMO. tomlq is still useful and it would not be possible to install it with Conflicts on the main package. Even though yq can process toml also. I guess omitting alternatives makes it clear, that they are not drop-in replacements. They have similar format, but python needs mandatory json filter. yq does not. At least on my Workstation python version reuses already installed modules and tools, making it more compact in result. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2263790 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202263790%23c42 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
