Hi Pedro,
Am 31.03.19 um 04:30 schrieb Pedro Pessoa:
The ideia for the "local" package is to make a clear distinctions
between remote and local files. Like so:
[ root ]
|- - oll-core
|- - edition-engraver
|- - lalily-templates
|- - ... etc
|- - [ local ]
|- - common (shared functions for local packages)
|- - lalily-templates (user extended files)
|- - drum-styles
|- - ... etc
I'm not sure if it is a good idea yet, I'm not the best folder architect.
The problem I see with this is that "local" is a generic name that might
be confusing when you talk about it. People (and maybe you in a couple
of months) will understand: "This is a local package", instead of "This
is the 'local' package". "\loadPackage local" simply doesn't "speak"
enough. Similar concerns exist agains naming variables "global".
Of course you can do what you want with your private packages, but I'd
rather use a name like "pp" (for your initials), or even
"my-local-package".
At first I created 'local' to store some extented files for
lalily-templates that I didn't wanted to put in the main folder.
At this point I wasn't even trying to use it as a package.
Then I thought I could move all my messy stuff (that were in the same
level as 'root') into it and enjoy package niceties, without messing
with real packages.
About the options issue, it may be unrelated, but I also noticed I may
have not "installed" it 100% properly.
In the 'package.ily' of "local", I tried using something like "
\loadModule local.common ", but it would raise a clueless error.
In my 'test.ly <http://test.ly>' file I could load the same module
with no errors.
Sorry, but without information about the "clueless error" I can't
comment on it
If there is some kinda of instructions on how to structure a package I
could check myself if I followed the right track.
Unfortunately not. You hit a weak spot with this ... :-(
But your original problem with the order of operations when loading
options I think you're hitting exactly this issue:
https://github.com/openlilylib/oll-core/issues/39. Having someone else
being disturbed by this might increase my incentive to think about a fix.
Your workaround seems reasonable you shouldn't be in the place needing
it in the first place.
Best
Urs
-- Pessoa
On Sat, Mar 30, 2019 at 9:17 PM Urs Liska <li...@openlilylib.org
<mailto:li...@openlilylib.org>> wrote:
Hi Pedro,
Am 30. März 2019 23:45:07 MEZ schrieb Pedro Pessoa
<pedrops...@gmail.com <mailto:pedrops...@gmail.com>>:
>Hello,
>I'm trying to use OLL infrastructure to organize my local
toolset. I'm
>mostly trying to mimic the structure of other packages and modules.
>I've an
>aparently working package called 'local', where I intend to put
all my
>personal tools as modules/submodules.
>
You may be surprised but I've never read from someone actually
doing this - although it's exactly how it was intended.
I would just recommend using a more specific name than "local".
>I'm currently having an apparently simple problem dealing with
options.
>The option I set on the loadPackage or loadModule "\with" does
not take
>precedence over the value used in register the options.
>
>Eg:
>%%% file: local/package.ily
>
>\include "oll-core/package.ily"
>\registerOption local.option "A"
>#(display (getOption '(local option)))
>
>%%% end
>
>%%% file: whatever/project.ly <http://project.ly>
>
>\include "oll-core/package.ily"
>\loadPackage \with {
> option = "B"
>} local
>
>%%% end
>
>-- Outputs: "A"
>
>
>
>
>I've came up with a workaround, but then I tought that is most
likely I
>just
>don't know how to proper handle it. "\registerDefaultOpt" is a simple
>function that only register the value if the option is unregistered.
>
>%%% file: local/package.ily
>
>\include "oll-core/package.ily"
>\registerDefaultOpt local.option "A"
>#(display (getOption '(local option)))
>
>%%% end
>
>%%% file: whatever/project.ly <http://project.ly>
>
>\include "oll-core/package.ily"
>\registerOption local.option "B"
>\loadPackage local
>
>%%% end
>
>-- Outputs: "B"
>
>
>
>So the question is: how to properly handle this?
I'll look into it (but not tonight). Right now I can't tell if you
are dealing with a limitation I still have to remove.
Urs
>Cheers,
>-- Pedro Pessoa
>
>
>
>--
>Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html
>
>_______________________________________________
>lilypond-user mailing list
>lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
>https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
