[BUG] In manifest mode it is not finding scripts in subcategories like `Privacy` and `Peripherals`

[4ntsy]

Wouldn't it be better and even easier if the path to these scripts were stored in a json file? This would avoid excessive recursion and simplify the analysis process, contributing to better performance... e.g. scripts.json

{
	"scripts": {
		"categories": [
			{
				"devs": {...}
			},
			{
				"utils": {
					"privacy": {...}
				}
			}
		]
	}
}

Regarding the Manifest, wouldn’t it also be an option to have it in another format, such as toml or ini? It would be easier for both users and developers, as it is easy to read and wouldn’t require so many parses. Example: manifest.ini

[toys]
packages = vim git
flatpaks = com.belmoussaoui.Authenticator im.dino.Dino
scripts = psypicks jetbrains-toolbox

[psygreg]

It's far easier to keep it as is and just fix it in the parser.

Having to update the json file everytime a new script was added would make pull requests adding new scripts clash with each other and unable to merge cleanly, and make script development, which is a big point of LinuxToys, less convenient.

The general idea of the manifest being plain text is to be as simple as it possible could be. 'toml' or 'ini' format parsing would introduce more variations that would have to be documented - and we all know following documentation seems to be a massive struggle nowadays. With the manifest feature as it currently is, as long as the header (first line) is there, it will read correctly, regardless of the ordering of elements, which makes it essentially foolproof. Besides, having everything being checked for scripts first is a feature, as packages that have scripts to install them, many times, have those because they need specific fixes, that, if not applied, will cause the application to not work as expected for the user.

[4ntsy]

Wouldn't it be interesting to create a separate branch for contributors, where they could submit their scripts? These scripts would only be merged into the master branch after being tested and validated.

Because in the current way someone can obtain the master via git and have instabilities...

This applies to other things, like contributing to interface or core...

[psygreg]

Wouldn't it be interesting to create a separate branch for contributors, where they could submit their scripts? These scripts would only be merged into the master branch after being tested and validated.

Because in the current way someone can obtain the master via git and have instabilities...

This applies to other things, like contributing to interface or core...

As of now, I manually check every PR - which means both reading through the code and cloning the fork and running it to see what was done, and what I may need to adjust. Then I only merge it when I believe the feature is either good enough as is, or I can immediately fix it to the desirable state when merged.

In the past, I used a branch system for development, but that didn't quite work due to the need of backporting fixes here and there, specially to Resolve and LSW, which don't follow or care about our release cycle, which made the branches unable to merge with the master cleanly and caused some nightmarish situations to fix. Many other decisions that I had to make, were made for the same reason: adapting to certain feature's release scheduling and requirements, because it was either that or ditching the feature entirely - which at least for me, was never a real option.

[psygreg]

This did give me an idea tho: using the source zipfile from the releases for the 'standalone running without installing' rather than git clone. I'll be changing the readme and docs to accomodate that soon.