With this you can version control your codea projects, which makes management of large projects much easier. It does require a few steps to setup, so it’s targeted at expert Codea users, but if you’re new and want to try it too, let me know how it goes.
I’m releasing here after consulting with @Simeon. I understand that other users in the forum think this might be frowned upon by Apple, and put some Codea features at risk, and they make some good points. However I felt that since this requires breaking Codea out its sandbox and significant tinkering under the hood to get it working, that it was ok to release.
Very interesting - I wonder how easy (or hard) it would be to replace github with your own server.
Semi related, I was working on a side project (since sidetracked due to insane amounts of work work eating at my free time) to do a Codea import/export as a seperate Cydia project for jailbroken ipads.
I’m far less concerned about this sort of hackery than I am about loadstring() shenanigans, but I’d still rather see it built-in to Codea (ie. all of the above, but local repos).
@juaxix, what @simeon said. Basically break codea out of the sandbox by copying the luasandbox.lua file so that the tool can do i/o on your project files. The github link has some instructions on how to install. Please let me know if they don’t work or are unclear.
@juaxix, it’s pretty messy code, some parts better than others. The Apple* classes are specially messy. I’ll clean up that code later and probably release as a standalone library.
Hello @Simeon. Can you provide more explanation about what has been enabled and what remains disabled? For example, I note that @ruilov’s code uses os.getenv("HOME") before making use of os.read(filename, "r").
yes, I’m having the problem of using getenv, and I believe I read elsewhere in the forum that it wasn’t enabled. I also can’t seem to get the code to actually download source, and it dies on the os.getenv(“HOME”) line, ProjectLoader.lua, line 21. So…