So... What you are saying is that we don't need 'install.md'. Because a developer can just use a LLM to generate a 'install.sh', validate that, and put it into the repo?
Good idea. That seems sensible.
Bonus: LLM is only used once, not every time anyone wants to install some software. With some risks of having to regenerate, because the output was nonsensical.
> What you are saying is that we don't need 'install.md'
I think the point was that install.md is a good way to generate an install.sh.
> validate that, and put it into the repo
The problem being discussed is that the user of the script needs to validate it. It's great if it's validated by the author, but that's already the situation we're in.
> The problem being discussed is that the user of the script needs to validate it. It's great if it's validated by the author, but that's already the situation we're in.
The user is free to use a LLM to 'validate' the `install.sh` file. Just asking it if the script does anything 'bad'. That should be similarly successful as the LLM generating the script based on a description. Maybe even more successful.
I still dont understand why we need any of them. If I am installing something, It would take me more time to write this install.md or install.sh than if I just went to the correct website and copied the command, see the contents, run it and opening help.
And since LLM tokens are expensive and generation is slow, how about we cache that generated code on the server side, so people can just download the pre-generated install.sh? And since not everyone can be bothered to audit LLM code, the publisher can audit and correct it before publishing, so we're effectively caching and deduplicating the auditing work too.
Shell scripts can be audited. The average user may not do it due to laziness and/or ignorance, but it is perfectly doable.
On the other hand, how do you make sure your LLM, a non-deterministic black box, will not misinterpret the instructions in some freak accident?