Hi Per
Per Eckerdal wrote:
Hi.
I have finally decided it's time to release the embryo of a module system that I have written.
Cool, thanks for releasing.
I don't have time to really look at it right now, though; I'll be back coding in the beginning of february.
Some things worth noting:
License:
I don't know what license to distribute it under, so right now I have decided to not choose any formal license at all and just informally state that you're free to read and poke around with the code. The reason for this is a thread on the gambit mailing list a while ago that was about adding a BSD (or MIT) style license, but someone said that if that should be done there is little reason to keep the LGPL/Apache. To me it seems like it's best if this is resolved before people actually start working on improving this piece of code. I'm not particularly biased towards any license, but I do think a simpler license scheme is better than a complex one all else being equal.
I personally find it difficult to generally understand all the issues around licences; I don't feel dual licensing makes matters more complicated; neither for deciding upon a license for a project (since you have to understand what you want your users to be able to do anyway first) nor for a user of a project (since the user can simply choose whatever license he likes or knows, it may make matter even simpler for him); might it make a difference is for a user wanting to contribute to the project?
I'll be happy to contribute to a discussion about licensing when I'm back working (either here on the list or on IRC).
Anyway, as long as the contributors are few and stay reachable until the discussion has happened, it should be no problem just choosing a license now already (in the worst case you'll have to toss away a contribution and rewrite it yourself); I'd suggest the same licenses as Gambit's current ones, since that's what I'd be using for my own contributions too (so we can easily move or share parts).
- It strictly replaces Gambit's current namespace functionality. You
can load object files that are compiled with it, but that's about how far you get in terms of interoperability. IME Gambit's namespaces simply aren't nice to work with.
(I'll like to discuss this when I'm looking at it. As I've discussed with James Long some time (*), I wonder if renaming couldn't use Gambit's namespaces too and conversely code using Gambit's namespace feature couldn't be made accessible cleanly from automatically-renaming code.)
(*) http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Module_System/Log
- define-macro gets tossed away. There's a lot to say about this
topic, so I'll leave it until later.
Yep, this will be getting at the interesting parts then.. ;-)
.. the tarball can be found here:
I suggest you check it into Git now; this will help against future confusion. If you don't know Git already:
tar xzf module.tar.gz cd module git init git add . git commit
Then you could either tar it up again and offer it instead of the current tar, but better:
log into your server cd /your_http_root_dir/apps/files/ git init mv -i .git modules.git # depending on git version: chmod +x modules.git/hooks/post-update # or mv -i modules.git/hooks/post-update.sample modules.git/hooks/post-update
and then from inside the git'ified module/ dir on your local machine:
git remote add publish ssh://user@your-server/your_http_root_dir/apps/files/modules.git git push publish master
Christian.