-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This completely changes the way the path options are handled to determine installed binaries. From each given path possible binaries are searched - in locations matching binary releases and custom builds - with the given path seen as - an installation dir or - a parent dir for multiple installations - the directory containing the 'lilypond' executable
- Loading branch information
There are no files selected for viewing
7 comments
on commit 41a6920
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this patch and how the path handling was changed. Problems I see now:
- I seem to be unable to use wildcards like
~/my/path/*/bin
before. - The searching algorithm finds
/usr/bin/X11/lilypond
which can not be run (it is executable but does not find the necessary internals of lilypond). It is able to state its version, though. So this might even be used and then fail. - Probably more because I can't test it in the current state (I can't use my custom lilypond versions, because they are not found).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the space separator should be re-enabled because we can use shell globbing then -p my/path/*
just works. Or we have to use the glob module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, there's two different things here: You don't understand what I intended with the patch, and I'm don't sufficiently aware where LIlyPond installations can reside beyond the two ways I have them.
The basic assumption is that the given path is the top level directory of a LilyPond installation. (e.g. ~/software/lilypond/releases/2.18.2
). Relative from there it looks for a lilypond
executable in either usr/bin
(binary release, installed for the user) or out/bin
(local build). The second assumption is that the given path is a parent directory containing multiple installations (in the above example this would be ~/software/lilypond/releases
which contains 2.18.2
, 2.19.54
and others). So all the subdirectories of the path are searched automatically and the *
isn't actually necessary anymore. But OTOH this is why /usr/bin/X11/lilypond
is found. The third assumption is that the given path directly contains a lilypond
executable.
So that is what the current behaviour does, now to what it does (or know) not. I don't really know what's happening when running the binary release installer with sudo, i.e. install lilyPond globally, and I don't know how installations from the Linux distribution packages work. So these are the cases that may not be properly handled ATM.
Could you show where your LilyPond files reside (i.e. what led you to your implementation fo the searching)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Top level of LilyPond installation sounds good. I have it in ~/path/sw/ly/lilypond-2.19.50-1/
for instance. The next sentences might be the problem: The executable is in ~/path/sw/ly/lilypond-2.19.50-1/bin
, not ~/path/sw/ly/lilypond-2.19.50-1/out/bin
or ~/path/sw/ly/lilypond-2.19.50-1/usr/bin
. I wonder why it is not found in ~/path/sw/ly/lilypond-2.19.50-1/lilypond/usr/bin
which is also present. But here I get a PermissionError from the check_output
in lyversions.py:55. Apparently, it tries to execute lilypond directly in the base directory and it does not even exist.
I am fine with searching through all subdirectories. It will probably result in too many occurrences because every installer already contains at least two lilypond
s. I have never encountered the right executable not being directly in a bin folder. So this could be an easy way to prevent the /usr/bin/X11/lilypond
. IMHO it's better to look at all default places instead. I found these so far:
- binary from website:
$PATH/bin/lilypond
$PATH/lilypond/usr/bin/lilypond
(we could drop this ...)
- Linux system:
/usr/bin
- Custom build:
$PATH/out/bin/lilypond
- Windows:
- ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One misconception on my side: if we look for bin/lilypond
or in out/bin
and usr/bin
all occurrences above should be found.
The permission denied is perhaps just a matter of the os.access and we need something like isfile
to skip directories. I can't look at it right now. I will in the next days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some clarifications:
1
When you say "binary from website" you mean installed through the downloaded shell script, not using sudo
? And what is $PATH
referring to in this case (it looks you mean the home directory)?
2
I assume you have a file /usr/bin/lilypond
present? (I obviously can't install lilypond through the package manager as there is "no installation candidate" - presumable because of the Guile2 issue). If you could you please try cat /usr/bin/lilypond
, as I think this is the wrapper script?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The permission denied is perhaps just a matter of the os.access and we need something like isfile to skip directories.
Maybe this has to do with the difference between the lilypond
executable and the wrapper script with the same name. I'd have to know which file causes the error - maybe check with a print()
statement before that line?
@joram-berger Actually I'm not sure how to deal with the first two default paths.