Add support for modules

[noteflakes]

In order to support more complex packages (like for example openlilylib), introduce support for sub-package modules:

\require "openlilylib@0.3.1/control_points"

In that case, instead of loading openlilylib@0.3.1/package.ly, lypack will load openlilylib@0.3.1/control_points.ly

A possible problem is a case where you have a package which package.ly file includes all its files. Requiring the package in the normal way, and later requiring a specific file of the package in either a user's file or another dependency, will lead to the same file being included twice.

[noteflakes]

One one to solve the problem with including a module twice would be to add an \includeOnce command. In order to implement such a command, we need:

A function returning the directory for the current file:

thisDir = #(define-scheme-function (parser location)()
  (dirname input-file-name))

A function to expand a filename:

This is a bit more tricky:

expandPath = #(define-scheme-function (parser location package)(string?)
    (cond ((char=? (string-ref f 0) #\/) f)
          ((string=? (substring f 0 2) "~/")
           (let ((prefix (passwd:dir (getpwuid (geteuid)))))
             (string-append prefix (substring f 1 (string-length f)))))
          ((char=? (string-ref f 0) #\~)
           (let* ((user-end (string-index f #\/))
                  (user (substring f 1 user-end))
                  (prefix (passwd:dir (getpwnam user))))
             (string-append prefix (substring f user-end (string-length f)))))
          (else (string-append (getcwd) "/" f))))

The above function doesn't handle "." or "..".

[noteflakes]

Since this kind of feature is probably going to be used only by openlilylib, and since @uliska is not yet decided how to proceed forward with refactoring the openlilylib code, I'm closing this.

[uliska]

I didn't previously notice this "issue" could be related to openlilylib, so I only now looked into it.

But yes, I think it makes sense to implement such functionality in openLilyLib itself.
openLilyLib will implement its own function for loading "modules" from within a library. The dependency issue can easily be circumvented here through the fact that any modules included in a library/package simply is from the same version as the main library/package.

The user will then use

\require "some-openlilylib-package" % optionally with a version
% This will implicitly load oll-core

\useModule "some-openlilylib-package.some-module"
% oll-core will handle to resolving of the path to the module
% This does make sense as oll-core also provides the posibility
% of passing options to modules

With regard to your expandPath sketch I can say that oll-core will provide even better support for things like this than the previous openlilylib. It has an os-path.ily core module that provides (already a number of) OS independent functions for path handling. The idea is providing much core functionality in such a place and allow packages to make use of it.