@girish I fixed the 'deno' issue
Pushed update to git.cloudron.io/timconsidine/cloudron-gristcore

Cloudron App Packagers
@girish I fixed the 'deno' issue
Pushed update to git.cloudron.io/timconsidine/cloudron-gristcore

@LoudLemur very good ... now that I can read it 
A little "opinionated" in places, but that's fine if that's how you want to manage your AI. I prefer a little looser. Some things have to be told (e.g, RO/RW), others can be more guided.
| S3 Storage |
minio|
Hmm, should we be saying this ?
I don't recall the issues exactly about minio, just decided to stop using it as unreliable in terms of the future, so closed my mind to it. And I don't recall what is Cloudron official stance
In any case 'minio' is not listed in Addons in Cloudron docs, so this should not be in the same section as the other elements.
But plenty of S3 options, Hetzner, Scaleway, others. And I packaged GarageS3 with UI, which is working nicely for me (still a custom app)
cloudron/base:4.2.0
I am packaging everything with 5.0 now
Application expects: /app/code/config/settings.json β READ-ONLY at runtime
You must provide: /app/data/config/settings.json β Actually writable
Solution: Symlink /app/code/config β /app/data/config
I think some AI can mis-understand this, that the emphasis is not only that it should be in /app/data, but that it must be called settings.json
Better as :
/app/code/[config/][settings.json|config.json|.env]
AI will understand the point better.
Control your AI agent, but empower it - it has knowledge and experience which you don't have. If you're too dictatorial, you'll get what you have always got. A little bit of permissioning, and you might find some nice new more efficient ways of doing something.
LICENSE added, in sync with Forgejo
@girish oops yes I will put a licence this morning
I find gitea UI a touch dated but itβs a git tool so most interactions via terminal or script, so maybe it doesnβt matter.
But Forgejo seems a touch fresher
@timconsidine can you throw in a license? I literally just moved to gitea from gogs
but maybe I will move to forgejo...
I packaged Forgejo.
My git repo : https://git.cloudron.io/timconsidine/cloudron-forgejo
not added to CCAI catalogue yet
@LoudLemur said in Packaging Applications for Cloudron Using AI:
I often run into the situation where so much of the AI's context has been consumed that its capabilities really start deteriorating.
This is certainly true - you're right ! 
Excellent thread.
I look forward to hearing others' thoughts, as I sure want to improve my process.
Personally, I'm not convinced about some points.
It's just my 2p, and others may have a different view.
@LoudLemur said in Packaging Applications for Cloudron Using AI:
One key thing that team cloudron could do to help with a modular step one is to provide the specifics that would remain the same for packaging in every project.
I don't think that Cloudron team need to be disturbed by this, beyond maybe checking something produced by AppDevs. It's all in the docs, barring some hard-won tips and tricks. AI could summarise it if it was asked. Or an AppDev dives in with their understanding. Maybe a Fider instance could be a good format.
@LoudLemur said in Packaging Applications for Cloudron Using AI:
To Do list.
This keeps the ai coder using the blueprint on track as it goes through the massive coding. It completes the tasks and then ticks them off its list and knows what to do next.
I find this is not needed.
Any decent dev assistant does this anyway as part of its workings. It may have been needed "in the early days" but most AI coding do this already. Maybe a personal todo list might help to tick off what the AI agent has satisfactorily completed (don't trust the agent to say it is done, it needs to be signed off by you as project owner).
@LoudLemur said in Packaging Applications for Cloudron Using AI:
Interview
You dump your initial idea and then ask the ai to ask you a single question at a time until it is satisfied it has the basics to create a spec sheet.
Hmm, seems a long winded approach. What I do is either :
I don't think we will add a new container runtime. gVisor needs one - https://gvisor.dev/docs/user_guide/install/ . We have to get grist working with pyodide somehow.
BTW, is https://www.nestybox.com/ dead? Gives me bad cert error.
@robi cool !
Reluctant to switch dev setup mid-project but next one will try it out.
Hoping to get Appflowy and ZeroNet out the door soon.