I’ve built up a bunch of classes and utility functions that I want to share between my projects. Currently I copy them between projects, but whenever I fix or improve one I have to copy it back to all the other projects that use it. It’s becoming quite a pain.
I’d like to be able to pull this common code into libraries that I can share between projects somehow.
I think we’ve requested this before, but I almost re-requested it last night. (I want that data dumper that got posted easily available!)
As a sort of meta-thing, maybe we need a sticky thread of suggestions and their disposition (on the way, like it but not in the pipeline yet, and won’t do it here’s why)
We need an issue tracker. A discussion forum doesn’t work well for that. A free one at Bitbucket, Google Code or GitHub would be a good start.
–Nat
I agree. These forums were put up in a hurry when we realised Codea was getting popular. We are still looking for a good issue tracker, while also fixing issues!
As for the topic at hand, Shared Libraries sound great. Not sure how it would be done from an interface point of view. Will talk to Simeon about it.
Yeah I’ve been thinking about this.
My first thought was to allow you to select files from other projects when you press the “+” button on the tab bar – however this would simply copy the file into your project. You would then need to delete and re-add any files when you update your library code. So this is not the best.
I’m hesitant to add proper library support because it complicates code sharing. When Projects are standalone they can be passed around easily. I guess we could add the ability for projects to depend on other projects. But then we need to tackle cyclic dependencies.
I’m happy to hear any suggestions about this.
Related to this someday it would be nice to refer to the common code of other users. I’ll be able to be more clear once code can be automatically downloaded. But, basically it would be nice to have a file that refers to specific user files elsewhere.
In other words if one wants to use a certain version of Bortel’s fonts, it would be great to have that refer directly to Bortel’s git of a certain version instead of reposting other people’s kewl stuff.
re. code sharing - have an “export project” button, that zips up the project, and it’s dependencies, and lets you send it… somewhere. either a github upload, or to mail, or to another app or whatever.
On the far side, “import project” would look at an incoming project and it’s libraries, and if you already had a library with the same checksum, use that?
Yeah - it’s getting awful close to package management and such. It’s frankly not a pretty problem, and I’m not sure any solution will wrap it up nicely. (Maybe a way to tie a project to github, where it updates there and you can simply pull a new version down?)
Another thought, again around github: maybe
require("github:bortels/HersheyCodea") -- or just a http:// URL?
and we could, behind the scenes, download it first time then cache? Point being - you don’t have to put the whole code in each project. (I’d also have to take the demo stuff out of “main.lua”, but whatever)
Why copy a required file from other project into existing project? Why not just use it directly from the project? iOS allows in-app filesystem after all. Lua has built-in file import feature. Why not just use both features? Why make it seems complicated? Every decision has its own advantages and disadvantages. With explicit import syntax, users KNOW that s/he needs the extra files. When user needs to export the project, Codea should include all the required files into the exported project package.
I personally disagree with online code sharing because it will always requires internet connection. Why not just download it from url or email into a project? If user wants to update the code with the latest, s/he could simply redownload it to override the old file(s). I think it’s pretty simple and straight forward.
bee: Lua in Codea doesn’t touch the filesystem, which is why there is no require. But I agree that a simpler solution is better, and I don’t want shared projects to externally reference files – they should be self contained when shared.
I will implement adding files from other projects, which will copy them over. This will at least make it easy to pull common code in from other sources, however will not keep it up-to-date automatically. We can explore future library systems after that.
AFAIK, Lua in iOS DOES touch the filesystem. Of course, it means in sandboxed manner which only allowed to access all files WITHIN the main app (in this case is Codea). At least I saw it being implemented on other Lua scripting app (iLuaBox which supports almost all Lua’s multifile features e.g. require, dofile, loadstring, etc). CMIIW. Even if it isn’t allowed, Codea should be able to simulate similar behavior such as being used currently on multifile support (also on simple database support on the new update). So, don’t say it’s the problem with Lua. It’s Codea “policy”.
I could understand the policy, for better or worse. What I’m expecting is a true cross project multifile support. Not just copy the file from other projects. At least provide a special folder, say “library” or something, which can be accessed by ALL projects. And don’t forget to include all the required files when a project is being exported, so there would be no problem with code sharing. Is it difficult to provide such mechanism?
Btw, why does it take so long to deliver the update? 
“Lua in iOS” makes no sense. iOS doesn’t include Lua. Codify/Codea does. And right now, in Codify, Lua does not touch the filesystem - it makes API calls to the Codify app, and the app accesses the filesystem. The difference is minor, but important.
Keep in mind - What Codify/Codea can and will do is very largely dependent on what Apple allows it to do - not just in the APIs they present, but in the apps they will approve. And Apple is skittish, and has historically been skittish, and having end-users be able to write code that modifies the file system, even the app sandboxed filesystem, is scary to them - not without reason. The Codea devs are walking a fine path between Apple (who they don’t want to annoy) and their end users (who they don’t want to annoy), and Apple and us want entirely different things. Apple wants quiet and stability and predictability, and we want to get into it and poke this thing in the guts. It may be that doing what you want - allowing full access to the iOS sandboxed filesystem - is the very thing that would prevent Apple from approving the next version of the app at all. And it may be that it’s harmless.
I’d cut the Codea devs a nice chunk of slack - they’ve seen the request, they agree in principle that movement in that direction would be useful… I’m inclined to suggest we let them cook on it for a while and see what they come up with; arguing semantics with them keeps them from doing what we want em to do. 
bee: I’m not saying Lua can’t, just that Lua in Codea is not designed to interact with the filesystem. That is, Lua is not sitting in a working directory: Codea abstracts over all files and passes the code directly to the interpreter. Again, I’m not claiming it’s a problem with Lua, nor is it Codea “policy.” It’s simply the way the system is designed. Codea handles files, projects, assets, sharing and editing. Lua handles interpreting code.
Regarding the update: I’m quite annoyed with how long Apple is taking. It simply sits there saying “Waiting For Review.” Every time I contact the App Review team I get the same answer, telling me to be patient.
Whether the additional file is accessed by Lua itself or through Codea, cross project file support should be doable. In fact, it’s already there on the current version we are all using now. IMO, it’s just a matter of adding cross project path to the file access. If it can’t be done dynamically, for whatever reasons, then make it hardcoded as special “library” path. In my understanding, the feature is already there. We just need to “tweak” it a bit: add cross project path.
Of course, Codea devs have all their rights to do what they think the best to do for Codea. Apple has their rights as well. I fully understand their policies. I didn’t suggest such “poke things in the guts” things that would break or jeopardize the system, nor required to redesign the whole app. Such feature even has been provided by other apps without problems (again, see iLuaBox, it’s free). Unless there is something I don’t know, or I missunderstood, I don’t see any sensible technical reasons to NOT implement this. That’s why I said it’s a “policy” of Codea devs. Please, enlighten me. I’d be happy if I’m wrong in this case.
Regarding the language, please forgive me if the “tunes” of my words sounds demanding. I never intend it to be that way. English isn’t my primer language, not even my second. I just don’t know how to make it sounds more polite. Keep in mind that I’m a happy Codea user. I know I haven’t made any good games like the others, but I like playing around with Codea.
It doesn’t matter if you plan to “poke it in the guts” (ie. mess around with stuff that makes Apple uncomfortable), or if I do - Apple has to look at it from the standpoint of “what will a bad guy do with this”. They will assume the worst because someone will try just that. We hope/assume that the sandboxed app filesystem is secure…
I’m not 100% convinced that simply throwing open the local filesystem solves the libraries and app packaging issues anyway, to tell the truth - this seems something that requires more design to come up with a real solution…
re. iLuaBox - I hadn’t seen that… but at $10, plus $10 for most major libraries, it’s far from free (unless you meant “free for the devs to implement” - and I don’t actually see arbitrary graphics as available, just GUI) I don’t like much the concept of in-app purchases to get libraries, in large part because I’m cheap, but also because others would presumably have to have purchased the same libraries. I do think it may be instructive to look at it - because, apparently, in that app apple has allowed, for example, socket libraries - so if they push back, we can point at them as prior art.
Hi Bee,
We are aware of iLuaBox. The issue is not really a technical one. Codea is designed with certain limitations in order to give it the best chance of being accepted by Apple as possible (versions have been refused by Apple in the past). More than that, it is designed with certain limitations to leave room for creativity on the part of users.
Its probably good to note that we consider Codea to be its own language. Clearly its based on Lua, but we have no problem with adding/removing language features if we feel the benefits are worth it.
I was thinking of something much simpler: Codea would let me specify which other projects a project depends on. It would behave as if the code from the dependency projects was in the project that depends on them.
So, a “library” would just be a project without setup, touched and draw methods. When Codea can give projects different icons, then we could use the icon to indicate visually if the project is written as a library or an app.
How those dependency projects end up on my iPad – whether I wrote them or they were downloaded by some future sharing mechanism – is a whole other kettle of fish. I think it’s best to consider the two issues separately.
I like the idea of a sentence like PHP:
require("github:bortels/HersheyCodea")
please add it