I’ve had this idea for a while now and started implementing it over the last couple of days but would like to hear others opinions of the idea.
The basic premise is this; a Codea project that downloads, updates and launches separate projects from a GitHub repo (or multiple in the future). Members of the community can submit their projects allowing easy access for anyone using the ‘WebRepo’ project. Submission would be primarily based on the submitted project being stable, or even not if projects can be filtered and categorised.
I intend for the WebRepo project to be as minimal as possible to avoid excess bloat prior to running a downloaded project. As it stands, I am currently utilising the GitHub API to detect & download projects from a single private repo. The WebRepo project caches downloaded projects along with the GitHub provided sha hash to ensure we update files when required. The downloaded projects launch and run from within the WebRepo project.
This doesn’t currently make the downloaded projects available for editing within Codea but this could be explored in the future.
There’s a lot or room for additional features here: app searching, categories, filtering & source links to name a few. There’s no intention to have any form of paid projects.
The project is currently in a private repo but will be fully open sourced when I feel it’s in a presentable state.
If you have any ideas that you think could be beneficial then do please let me know! And if you think it’s a bad idea then let me know why.
Any opinions will be appreciated.
@Steppers - Codea used to have a library of routines and projects which was run from a project. Users were registered and could add and download code/projects from within Codea. That was before we were able to export zipped projects.
Could be worth searching for the project to get access, If it is still accessible, as there was quite a few projects and routines that Codea users had added to it. Unfortunately, I can’t remember what the management project was called. I’ll check my files and search the forum - if I find anything I’ll post the details. @dave1707 may have details,
@dave1707 - yup, that’s the one. Seem to remember @JMV38 was involved with others in the organisation.
When you say went bust I assume access is no longer possible.
@Bri_G I think there were problems with it after awhile and whoever wrote it/maintained it didn’t keep up with it. I didn’t use it except to see how it worked, so I don’t remember too much about it.
@Bri_G Just had a look on the forum here and from what I can tell it seems it offered something very similar to what I’m aiming for.
The difference I believe would be that my implementation wouldn’t rely on any custom server side program and instead utilise a git repo to handle things. Backing up projects was not within my initial scope so would probably not be a focus.
I’m hoping that by doing it in this way and having the WebRepo project source easily accessible (with other contributors also having access to the core repo for submission purposes) this could be sustainable into the future.
@Steppers - tend to agree with you. Let us know when you get your system up and running and I may have a few things to post. Will there be any supporting forum or text support pages?
@Bri_G Once things are up and running I intend to add another discussion here on the forum with links to the GitHub repo for managing releases & the wiki (all in the same repo as the projects hosted hopefully). If things go well then it may be worth making it a sticky post but we’ll see how it goes.
On the agenda is also the potential to have the WebRepo project autoupdate itself using the same logic as everything else with no effort from the user.
It should all be pretty much ready to go other than the project browser itself and the Wiki.
I’m aware of some issues that we may run into with assets but they should hopefully only require minor changes to submitted apps. Specifically, asset keys should only be using built in or project local assets as they’re the only ones added to the bundle when exporting.
So asset.documents.<something> will not work unless the project is absolutely certain that the asset actually exists (e.g. if the asset was generated by the project)
Other than that I hope you like the preview release!
I’ve been thinking a lot about why people don’t seem to use other people’s work very often in Codea.
Many many many projects have been posted to the forums with the idea that “this code should be helpful for someone who wants to do X or Y, or make X or Y kind of game”—I’ve done that myself a bunch—but as time goes on it doesn’t seem like anyone ever actually uses it, or at least it’s very rare that anyone does.
I think one of the problems is discovery, and I wonder if your project could help with discovery in a major way, and my conjecture is that for it to be the most helpful, the projects would have to be sorted by the category of thing that they could help with.
@UberGoober I totally agree and that’s one of the primary reasons I’m doing this. Increasing accessibility to community projects with minimal effort on the part of the user. Including automatic updates.
I’ve recently added a simple metadata system which we could use to add categories and/or tags to projects for ease of filtering and searching. I’d also like to add a link to a specific forum page for each project at some point so users can get more info & ask questions.
At the moment every downloaded project is considered executable but it could be expanded to support non-executable libraries too which could be great when it comes to community collaboration.
What I think would be the greatest for beginners is some kind of actual tutorial that went through several simple small projects, explaining each one, and then showed a larger project that put all of those simpler projects together.
If you could prioritize detecting if a project has an existing icon and, if so, using that icon in your menu, I’d really appreciate it, because I make an effort to give all my saved projects icons and it’s a little discouraging to not see them on the selection screen.
A few games including a lemmings clone (though using Codea only assets so you need a bit of familiarity with the original) as well as a few step-by-step starter tutorials. Not checked them for a while so some may not run - give us a shout if you need a hand.
Ok, I’ve invited you. You’ll probably have an email.
I have actually been thinking about the icon situation recently.
We have 2 options from what I can tell:
a) We store the .codea bundles directly in the repo rather than the compressed zip. file. This way the WebRepo project can download the icon directly from the repo. With the compressed projects we have to download the entire project to access the icon.
b) When adding a new project to the repo, we extract the icon from the project and upload it separately alongside the zip file, using a global metadata file.
I’m beginning to think the best option (and the cleanest) would be a) as doing that would mean I could also get rid of the global metadata.json and include additional info in the project’s Info.plist file instead (Display name, author, version, etc.)
By doing that each project bundle would also then support partial updates (per file) as the WebRepo project currently does.
