Re: Modularity in lilypond

[Graham Percival]

On Thu, Jul 29, 2010 at 08:17:38PM +0200, Mike Solomon wrote:
> True that.

Please do not top-post.

> My three.5 concerns are:
> 1) said code cannot use non-public scheme functions (am I right in thinking
> that?).

I'm not certain about this.

> 2) changes to init.ly are not copied from one version of lilypond to the
> next, nor are one person's "modules".  I do my compiling from the git
> repository, so I could likely rig something like that for my own machine,
> but I imagine this is even more problematic for someone downloading a
> GUB-made lilypond.  I had this problem with my site-packages when I updated
> from Python 2.4 to 2.6, and it took me days to get back things as I had
> them.

It would not be hard to add functionality to let people put their
own "modules" in ~/.lilypond/ or whatever.  In fact, Reinhold's
recent patch for --user-include already supplies this
functionality, although we might want to provide syntactic sugar
by adding a --module-dir option.  The "relative include paths"
feature, which may or may not be in the docs yet, also helps with
this task.

> 3) There should be some sorta standard practice (ie template) for how
> modules are written (I believe that's what David was referring to).

I don't think that this is what David was talking about, but of
course such templates would be useful.

And, by the way, I've been trying to recruit somebody to organize
/ly/ for at least the past three years.

> 3.5) I stand by my assertion that certain features of lilypond should be
> turned into modules if lilypond is to grow to be as encompassing as
> something like j-edit or emacs.

As a general rule?  Sure.


Look, you're mixing up a few issues.

1. what are the technical limits of the functionality which can be
added as the result of an \include "foo.ly" statement?
(loading libraries, defining non-public scheme functions,
redefining syntax, changing font heads...)

AFAIK, we don't have a clearly known+documented set of limits.
This would be useful to work on.


2. how should the dirs be organized?

This is an idea from 3 or 4 years ago.  Nothing is going to happen
until 2.14 is out.  And there's no point trying to seriously
discuss this until #1 is settled.


3. how can we make this easy for users?

No point discussing this until #1 is settled.


If people think that I'm not being very encouraging, I'd like to
remind them that we currently have 15 patches waiting for review
or revision, including 2 for Critical issues, and that we (as a
community of developers) are being terribly unsupportive in not
spending more effort helping those patches get finished.

Cheers,
- Graham