[R] Re-structure directories for consistency.

[xplshn]

Hi, I am requesting this because:

    switch runtime.GOARCH {
    case "amd64":
        validatedArch = [3]string{"x86_64_Linux", "x86_64", "x86_64-Linux"}
    case "arm64":
        validatedArch = [3]string{"aarch64_arm64_Linux", "aarch64_arm64", "aarch64-Linux"}
    default:
        fmt.Println("Unsupported architecture:", runtime.GOARCH)
        os.Exit(1)
    }

Makes no sense, why does the name used for the repos not match the metadata files? Why does one say Linux and the other not? It would make a lot more sense to have: Linux/amd64 and Linux/arm64 And you'd have Android/XY and Windows/XY

And a metadata file per architecture containing:
Name
Family (may be Null)
Description (may be Null)
Updated
SHA256 (must have, used for `update` in `bigdl`)

An example of what Family means would be:
Name: visudo
Family: sudo
Description: Utility to execute a command as another user
Updated: UTC date in ISO 8601 format. (e. g; 2024-09-04 18:00:00.000.)
Size: 484.54 kB
SHA256: TheQuickBrownFoxJumpsOvertheLazyDog43216789

There would be no universal metadata.json because that presents the following problems:

• Complexity (its too big to parse in less than 0.2s, best I can get using SIMD instructions and doing things in parallel is 0.22s)
• Generating the file is bound to be a complex task, sometimes programs end up with descriptions that don't correspond to them, or some other times the file is empty, sometimes there are duplicates. Proof:

This would also simplify the process of fetching information about binaries, because one json has a description but lacks other relevant fields or simply do not have an entry for some binaries, while the other json has everything except Description, Updated, Size and some other misc fields. What I have to do in order to display info about all binaries is fetch both JSONs and combine them, but that makes the functionality slow.

[Azathothas]

---

why does the name used for the repos not match the metadata files? Why does one say Linux and the other not? It would make a lot more sense to have: Linux/amd64 and Linux/arm64 And you'd have Android/XY and Windows/XY

You meant in the main metadata.json ?

"host": "aarch64-Linux",
"host": "x86_64-Linux",
"host": "arm64-v8a-Android",
"host": "AMD64-Windows_NT",

All of these are consistent with $UNAME-$OS

And if you mean the dirs at https://bin.ajam.dev, I keep telling people to just use $UNAME or $UNAME-$OS, as I have already setup redirects:

• https://github.com/Azathothas/Toolpacks/blob/main/Docs/METADATA.md#url-redirects
• https://github.com/Azathothas/Toolpacks/tree/main?tab=readme-ov-file#cli

---

It would make a lot more sense to have: Linux/amd64 and Linux/arm64 And you'd have Android/XY and Windows/XY

That's even worse. If you can't even parse a simple, well structured json, how do you expect to parse the ones containing / as that will create further confusion on if it's dir, or a string or path to a bin

---

Generating the file is bound to be a complex task, sometimes programs end up with descriptions that don't correspond to them, or some other times the file is empty, sometimes there are duplicates. Proof:

• descriptions that don't correspond to them : List them here, I would like to take a look
• some other times the file is empty : Because only bins whose repo exists on Github.com are given the hysp-enrichment treament. I don't have time to manually create description etc for thousands of packages. So if it can't be automated, it will most certainly not be manually added.
  • sometimes there are duplicates : This because all of those bins originate from a single Github Repo/ Source, and again, I don't plan to create manual entries.

---

because one json has a description but lacks other relevant fields or simply do not have an entry for some binaries, while the other json has everything except Description, Updated, Size and some other misc fields. What I have to do in order to display info about all binaries is fetch both JSONs and combine them, but that makes the functionality slow.

To this day, I haven't been able to reproduce https://github.com/Azathothas/Toolpacks/issues/10 and as stated in that issue, the most likely culprit is cloudflare caching. And I can do nothing about that other than tell my client (curl/wget) to ignore cache.

And as for the json data at: https://github.com/Azathothas/Toolpacks/blob/main/metadata.json , that's fetched from hysp. I don't own hysp. At the time I had free time and volunteered to create a system that would generate those fields. Creating this toolpacks repo, i had neither any need nor any interest on relying on such format as I prioritized number of binaries over binaries with good looking description. Even if I were to recreate hysps' format, you will still not have proper fields for everything because once again, I can only do what's easy to automate.

---

Your problem with these metadata related topics can be forever fixed by:

• create a new repo
• write github actions, to generate all needed fields in the format you prefer
• you can even create system where you can manually add entries to those that are not automatable. or fetch from sources like search.nixos.org
• you alone would have full control on the naming, formatting & structure of things
• you could add/combine additional repos etc
• finally you use that repo as the primary source for your tool.

This will cost you only time and nothing else as github actions is free for public repos. You won't have to rely on unreliable formats/data/repos.

[xplshn]

That's even worse. If you can't even parse a simple, well structured json, how do you expect to parse the ones containing / as that will create further confusion on if it's dir, or a string or path to a bin

I don't see the problem, what would the struggle be? I don't parse JSON to perform downloads, that's only for metadata. I am also not asking for more metadata, nor prettier-looking descriptions, nor more fields, in fact. I am asking for something simpler

And as for the json data at: https://github.com/Azathothas/Toolpacks/blob/main/metadata.json , that's fetched from hysp. I don't own hysp.

some other times the file is empty : Because only bins whose repo exists on Github.com are given the hysp-enrichment treament. I don't have time to manually create description etc for thousands of packages. So if it can't be automated, it will most certainly not be manually added.

It wasn't really a complain, Null is acceptable. But I need it all in a single place and in JSON format

sometimes there are duplicates : This because all of those bins originate from a single Github Repo/ Source, and again, I don't plan to create manual entries

Again, I do not care about quantity. Null is acceptable for some fields.

descriptions that don't correspond to them : List them here, I would like to take a look

I understand why, there's no problem with this example, I will make a list of them once I get back from school

You don't need to own Hysp for that, its a github action too, you can simply copy it and correct it if you want.

I will close this issue as a Won't Fix then