Curl matters

[ivan-hc]

Removed "jq" among dependences.

[Samueru-sama]

Remember that the way the version=$(FUNCTION) gets made has to be changed to not depend of whether the json is human readable or not if you are doing this Ivan.

Because very likely what happened with wget2 can happen with curl as well in the future. And that issue can be greatly mitigated if the scripts get parsed like the speedcrunch script for example.

[ivan-hc]

@Samueru-sama I've learned this a lot before getting this choice.

We can't compare the issue wget/wget2 with curl, and the reasons are very simple:

• wget and wget2 are two different programs, and the "genious" of the Fedora team have replaced a new program with a different one, because Fedora is "an advantgarde distro";
• curl will be never replaced with a curl2, because they are at version 8;
• curl on the contrary of "FUSE" and "wget" does not replace its components, but updates them, so the name is always the same;
• for curl exists a lot of official documentation on github to play with API rest;
• curl is widelly used, also in big tech;
• also come electronic components are using curl.

And I can keep going on.

What I'm saying is that since an official github documentation about curl usage with APIs exists, we are still safe.

Until the day that github and curl will divorce, we have all time to implement the several alternatives in our script.

And again, until that day, all installation scripts will e updated.

We have a lot of time for now. Github is not Fedora. One is a wordlwide platform for all developers with a documentation that promotes curl (without mentioning wget), the other one is an experimental distro aimed to release Red Hat, a commercial one.

[ivan-hc]

That said, I've been thinking about this solution for a long time... and eliminating "jq" from my project was a relief. It was too heavy a burden for me, both from the point of view of use and from the point of view of the decision that led me, in a hurry, to include it in the project, that damned day when we had too many open problems at the same time.

Now that we no longer have any problems we can work more calmly. Me first.

[Samueru-sama]

@Samueru-sama I've learned this a lot before getting this choice.

We can't compare the issue wget/wget2 with curl, and the reasons are very simple:

• wget and wget2 are two different programs, and the "genious" of the Fedora team have replaced a new program with a different one, because Fedora is "an advantgarde distro";
• curl will be never replaced with a curl2, because they are at version 8;
• curl on the contrary of "FUSE" and "wget" does not replace its components, but updates them, so the name is always the same;
• for curl exists a lot of official documentation on github to play with API rest;
• curl is widelly used, also in big tech;
• also come electronic components are using curl.

And I can keep going on.

What I'm saying is that since an official github documentation about curl usage with APIs exists, we are still safe.

Until the day that github and curl will divorce, we have all time to implement the several alternatives in our script.

And again, until that day, all installation scripts will e updated.

We have a lot of time for now. Github is not Fedora. One is a wordlwide platform for all developers with a documentation that promotes curl (without mentioning wget), the other one is an experimental distro aimed to release Red Hat, a commercial one.

The issue wasn't wget itself, the problem was a different user agent causing the json to be compact instead of human readable.

This can happen with with curl at any moment for any reason, even due to changes in github. It's ok to get rid of jq but lets make sure that the newer scripts do work if the json changes

[ivan-hc]

The issue wasn't wget itself, the problem was a different user agent causing the json to be compact instead of human readable.

I remember it very well, but what happened was a case more uniqe than rare.

For years we all have used wget and curl to fetch github apis, and wget2 is something different and not yet recognized by providers.

This can happen with with curl at any moment for any reason

I know, but from about two monts we are the only project that noticed and reported the issue, and the Fedora team that have done that choice is the one that have given issues to its users.

even due to changes in github.

OK, we don't know much about future choices of Microsoft for github apis, but github itself have a lot of documentation on how to manage its apis, and "curl" is one of these choices.

Again, curl is a more used project I guess, many companies already rely on it. If they decide to do something to break compatibility, I'm sure that they will adjust this in no time, since curl is an important piece of software for many services.

Not wget, and someone have had the brilliant idea of replace a Pepsi with a Chinotto (wget with wget2), they are two similar things but they act differently.

Github team has all interests on made these things work as they should, or they had not talked so much about curl usage, so it is a solid piece of software.

About wget, it is a great software, but not a solid one, since someone decided to replace it with another one.

We already know the story, I don't waste time again and again talking about Fedora choices and differences between a software or another.

But you, @Samueru-sama have said something we have talked about several times here and on Discord, i.e.

It's ok to get rid of jq but lets make sure that the newer scripts do work if the json changes

and this is what we must think now, to work on a new template. Are you still working on the one you shown me yesterday night? This i the point.

The only thing this PR was done is to get rid of one dependence. A so overrated dependece that for it were deserved 3 functions!

Now, stop talking about what I did today, none is dead, I've killed none, nor users have noticed that jq is no more a dependence.

Let move on and go think on how to convert this repository into a real AUR for AppImages. Please.

[Samueru-sama]

and this is what we must think now, to work on a new template. Are you still working on the one you shown me yesterday night? This i the point.

Nope, I only did the small changes of the recent PR that I opened.

the sed 's/[()",{} ]/\n/g' | grep etc etc is something that needs to be added to the templates module.