Re: wrap-program –> wrap-script
Hello! Ricardo Wurmus skribis: > I’ve just pushed a change to use wrap-script in one package. The > purpose of wrap-script is to wrap an executable without having to create > a separate wrapper shell script. It does this by prepending a Guile > script to the top of the file, which sets the environment variables and > then re-executes itself with the target interpreter (e.g. Python). Neat! > I noticed two things: > > 1) wrap-script does not automatically pull in Guile as a dependency, so > if Guile isn’t among the inputs it will create a bad shebang. This > should be fixed on core-updates. Or we could say that it’s not different from other shebangs: it’s up to the packager to provide all the necessary dependencies. > 2) we aren’t using wrap-script anywhere. I think a good use case would > be the Python build system’s “wrap” phase where we currently use > wrap-program. Most of the time we’d be dealing with Python scripts, so > using wrap-script would be more appropriate here. The would immediately reach hundreds of packages, so it’s a good idea! Thanks, Ludo’.
Re: wrap-program –> wrap-script
Efraim Flashner writes: > On Wed, Dec 11, 2019 at 04:57:41PM +0100, Ricardo Wurmus wrote: […] >> I’ve just pushed a change to use wrap-script in one package. […] >> >> 2) we aren’t using wrap-script anywhere. I think a good use case would >> be the Python build system’s “wrap” phase where we currently use >> wrap-program. Most of the time we’d be dealing with Python scripts, so >> using wrap-script would be more appropriate here. > > It turns out we are using it in vpnc-scripts. Yes, that’s where I added it right before writing my email. -- Ricardo
Re: wrap-program –> wrap-script
On Wed, Dec 11, 2019 at 04:57:41PM +0100, Ricardo Wurmus wrote: > Hi Guix, > > I’ve just pushed a change to use wrap-script in one package. The > purpose of wrap-script is to wrap an executable without having to create > a separate wrapper shell script. It does this by prepending a Guile > script to the top of the file, which sets the environment variables and > then re-executes itself with the target interpreter (e.g. Python). > > I noticed two things: > > 1) wrap-script does not automatically pull in Guile as a dependency, so > if Guile isn’t among the inputs it will create a bad shebang. This > should be fixed on core-updates. I thought the build systems had an implicit guile in them. Looks like I had that exactly backwards. > > 2) we aren’t using wrap-script anywhere. I think a good use case would > be the Python build system’s “wrap” phase where we currently use > wrap-program. Most of the time we’d be dealing with Python scripts, so > using wrap-script would be more appropriate here. It turns out we are using it in vpnc-scripts. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: wrap-program –> wrap-script
Hello Ricardo, Ricardo Wurmus writes: > Hi Guix, > > I’ve just pushed a change to use wrap-script in one package. The > purpose of wrap-script is to wrap an executable without having to create > a separate wrapper shell script. It does this by prepending a Guile > script to the top of the file, which sets the environment variables and > then re-executes itself with the target interpreter (e.g. Python). That's smart! > I noticed two things: > > 1) wrap-script does not automatically pull in Guile as a dependency, so > if Guile isn’t among the inputs it will create a bad shebang. This > should be fixed on core- Since as you mention below, the wrap-script isn't much used at all, I guess the reason to make the change to core-updates rather than master is because the host module of wrap-script (guix build utils) is used as a whole when computing the hash of derivations? > 2) we aren’t using wrap-script anywhere. I think a good use case would > be the Python build system’s “wrap” phase where we currently use > wrap-program. Most of the time we’d be dealing with Python scripts, so > using wrap-script would be more appropriate here. > > What do you think? Are you considering "testing" for the type of file (e.g., script? binary?) before wrapping it? Something else? I like the idea in general. IIUC this would remove the need to have those ugly .real-script-name lying around. Maxim
Re: wrap-program
Hello, I am only now catching up with the discussion. So far, I do not understand why we need a wrapper. Would it not be enough to add the environment variables $XDG_DATA_DIRS etc. to the search paths of the programs, in the same way as perl or python modules incite the user to define the corresponding environment variables pointing to a subdirectory of .guix-profile? For instance, I have the following in my .bashrc: export PYTHONPATH=$HOME/.guix-profile/lib/python2.7/site-packages:$HOME/.guix-profile/lib/python3.3/site-packages And I already have export XDG_DATA_DIRS=$HOME/.guix-profile/share This one was just good to have and, if I remember correctly, not suggested when installing some package, but it could be added to the packages needing it. Andreas
Re: wrap-program
Federico Beffa be...@ieee.org skribis: 1. GSettings schemas: More than schemas compilation, the problem is that the schemas are by default expected to be in $datadir/glib-2.0/schemas (with $datadir usually being /usr/share). In spite of this, other directories can be specified with the help of the environment variable $XDG_DATA_DIRS. Since at glib-2.0 compiled time we can't know the path of future application installations, we may want to define Right, that’s one of the reasons why the ‘glib’ package defines it as its search path (see glib.scm.) 2. gtk-3.0 modules: gtk+ looks for modules (like libcanberra.so) in locations specified by a. $GTK_PATH, b. $libdir/gtk-3.0/modules, with $libdir being the one specified at gtk+-3.0 ./configure time OR $GTK_EXE_PREFIX/lib. Option a. is inconvenient because that variable is used by both, gtk+-2.0 and gtk+-3.0, easily leading applications compiled with one version to find incompatible libraries. Option b. is more attractive. Again, at compile time we do not know the location of future modules installations: Take emacs: it looks in the gtk+-3.0 directory $libdir/gtk-3.0/modules. However, it is looking for a module installed by libcanberra which is not even an input to the emacs package. For this reason we should probably define GTK_EXE_PREFIX=$HOME/.guix-profile That would be easy and could be defined in /etc/profile on the standalone system. However that would force users to install GTK+ in their profile so that the modules it comes with are found, right? This would be inconvenient. We may just want to check that: (i) paths defined in environment variables are not duplicated by 'wrap-program' definitions (wrap launched by wrap) and (ii) if the variable is already defined (for non guix reasons), we may want to append the existing value. Yes, this is the preferred solution, I think (and I think it’s this case it’s OK to have these two variables leak in sub-processes, as discussed with Mark.) However, we’d like to factorize the extra phase that does the wrapping, so we don’t repeat it for each and every program. The only problem I see right now is if a program is launched by a user which does not have $HOME/.guix-profile (like a service). In that case there could be a default profile. I think these are mostly GUIs, unlikely to be launched by a service. This could also serve the second purpose of providing initial default applications (like guix itself!) to all users on guix on distro systems. Hmm what do you mean? Thanks, Ludo’.
Re: wrap-program
l...@gnu.org (Ludovic Courtès) writes: Federico Beffa be...@ieee.org skribis: 1. GSettings schemas: More than schemas compilation, the problem is that the schemas are by default expected to be in $datadir/glib-2.0/schemas (with $datadir usually being /usr/share). In spite of this, other directories can be specified with the help of the environment variable $XDG_DATA_DIRS. Since at glib-2.0 compiled time we can't know the path of future application installations, we may want to define Right, that’s one of the reasons why the ‘glib’ package defines it as its search path (see glib.scm.) I'm not sure I understand. Take emacs: the package does not have glib as an input. However, it does have gtk+, which defines schemas in its own tree .../gtk+-3.10.1/share/glib-2.0/schemas (and gtk+ is not an input to glib). Therefore, having $XDG_DATA_DIRS in the glib package does not help emacs. The emacs packge needs its own $XDG_DATA_DIRS pointing to the gtk+ schemas. GTK_EXE_PREFIX=$HOME/.guix-profile That would be easy and could be defined in /etc/profile on the standalone system. However that would force users to install GTK+ in their profile so that the modules it comes with are found, right? This would be inconvenient. Yes, so we should probably define $GTK_EXE_PREFIX in the emacs package with the full path (/gnu/store/...) and not $HOME/ And given that the gtk+ module is provided by libcanberra, the latter should be an input to emacs as well. Yes, this is the preferred solution, I think (and I think it’s this case it’s OK to have these two variables leak in sub-processes, as discussed with Mark.) However, we’d like to factorize the extra phase that does the wrapping, so we don’t repeat it for each and every program. Since I'm new to glib schemas and gtk modules, I'm trying to understand the correct broadest approach before doing anything. I think these are mostly GUIs, unlikely to be launched by a service. I was thinking about windows managers and desktops. Not sure they really need this. This could also serve the second purpose of providing initial default applications (like guix itself!) to all users on guix on distro systems. Hmm what do you mean? I was thinking about a convenient mechanism for providing packages visible to all users of a system. Regards, Fede
Re: wrap-program
l...@gnu.org (Ludovic Courtès) writes: Mark H Weaver m...@netris.org skribis: This 'wrap-program' strategy of setting environment variables before running a program has problems. In this case, it means that every program run within Emacs will inherit that GSETTINGS_SCHEMA_DIR value. Along the same lines, I've noticed that when running WindowMaker, all of the programs within my X session include a WindowMaker-specific directory at the front of PATH. It would be good to find another solution. I think whether using ‘wrap-program’ is a good strategy has to be evaluated on a case-by-case basis. In some cases it’s OK, in others (like wmaker), it’s not so nice. In cases like wmaker, another solution would be to patch the source code to execute directly the right binaries, without changing PATH. The downside is that it’s often less convenient to do. I've looked some more into the problems I've found with the emacs package: 1. GSettings schemas: More than schemas compilation, the problem is that the schemas are by default expected to be in $datadir/glib-2.0/schemas (with $datadir usually being /usr/share). In spite of this, other directories can be specified with the help of the environment variable $XDG_DATA_DIRS. Since at glib-2.0 compiled time we can't know the path of future application installations, we may want to define XDG_DATA_DIRS=$HOME/.guix-profile/share/:$XDG_DATA_DIRS. If the variable $XDG_DATA_DIRS is not specified, it defaults to /usr/local/share/:/usr/share/. https://developer.gnome.org/gio/stable/ch32s06.html http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html 2. gtk-3.0 modules: gtk+ looks for modules (like libcanberra.so) in locations specified by a. $GTK_PATH, b. $libdir/gtk-3.0/modules, with $libdir being the one specified at gtk+-3.0 ./configure time OR $GTK_EXE_PREFIX/lib. Option a. is inconvenient because that variable is used by both, gtk+-2.0 and gtk+-3.0, easily leading applications compiled with one version to find incompatible libraries. Option b. is more attractive. Again, at compile time we do not know the location of future modules installations: Take emacs: it looks in the gtk+-3.0 directory $libdir/gtk-3.0/modules. However, it is looking for a module installed by libcanberra which is not even an input to the emacs package. For this reason we should probably define GTK_EXE_PREFIX=$HOME/.guix-profile https://developer.gnome.org/gtk3/3.10/gtk-running.html Note: the documentation at this site mentions the directory .gtk-3.0 in $HOME. However, strace on emacs and the README in the gtk-3.10.1 source says that this path is no longer used. Setting the above two variables eliminates both problems (libcanberra and schemas not found) in the emacs package. We could probably define the above variables with 'wrap-program'. In guix on distro installations this would avoid having guix libraries interfere with a non guix program. On the other side, in a guix program launched from within another guix program, this should be harmless. We may just want to check that: (i) paths defined in environment variables are not duplicated by 'wrap-program' definitions (wrap launched by wrap) and (ii) if the variable is already defined (for non guix reasons), we may want to append the existing value. The only problem I see right now is if a program is launched by a user which does not have $HOME/.guix-profile (like a service). In that case there could be a default profile. This could also serve the second purpose of providing initial default applications (like guix itself!) to all users on guix on distro systems. And on the gnu system, well, there are system installed programs. Regards, Fede
Re: wrap-program
On Fri, Sep 26, 2014 at 10:09 PM, Federico Beffa be...@ieee.org wrote: l...@gnu.org (Ludovic Courtès) writes: Mark H Weaver m...@netris.org skribis: This 'wrap-program' strategy of setting environment variables before running a program has problems. In this case, it means that every program run within Emacs will inherit that GSETTINGS_SCHEMA_DIR value. Along the same lines, I've noticed that when running WindowMaker, all of the programs within my X session include a WindowMaker-specific directory at the front of PATH. It would be good to find another solution. I think whether using ‘wrap-program’ is a good strategy has to be evaluated on a case-by-case basis. In some cases it’s OK, in others (like wmaker), it’s not so nice. In cases like wmaker, another solution would be to patch the source code to execute directly the right binaries, without changing PATH. The downside is that it’s often less convenient to do. I've looked some more into the problems I've found with the emacs package: 1. GSettings schemas: More than schemas compilation, the problem is that the schemas are by default expected to be in $datadir/glib-2.0/schemas (with $datadir usually being /usr/share). In spite of this, other directories can be specified with the help of the environment variable $XDG_DATA_DIRS. Since at glib-2.0 compiled time we can't know the path of future application installations, we may want to define XDG_DATA_DIRS=$HOME/.guix-profile/share/:$XDG_DATA_DIRS. If the variable $XDG_DATA_DIRS is not specified, it defaults to /usr/local/share/:/usr/share/. https://developer.gnome.org/gio/stable/ch32s06.html http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html 2. gtk-3.0 modules: gtk+ looks for modules (like libcanberra.so) in locations specified by a. $GTK_PATH, b. $libdir/gtk-3.0/modules, with $libdir being the one specified at gtk+-3.0 ./configure time OR $GTK_EXE_PREFIX/lib. Option a. is inconvenient because that variable is used by both, gtk+-2.0 and gtk+-3.0, easily leading applications compiled with one version to find incompatible libraries. Option b. is more attractive. Again, at compile time we do not know the location of future modules installations: Take emacs: it looks in the gtk+-3.0 directory $libdir/gtk-3.0/modules. However, it is looking for a module installed by libcanberra which is not even an input to the emacs package. For this reason we should probably define GTK_EXE_PREFIX=$HOME/.guix-profile https://developer.gnome.org/gtk3/3.10/gtk-running.html Note: the documentation at this site mentions the directory .gtk-3.0 in $HOME. However, strace on emacs and the README in the gtk-3.10.1 source says that this path is no longer used. Setting the above two variables eliminates both problems (libcanberra and schemas not found) in the emacs package. We could probably define the above variables with 'wrap-program'. In guix on distro installations this would avoid having guix libraries interfere with a non guix program. On the other side, in a guix program launched from within another guix program, this should be harmless. We may just want to check that: (i) paths defined in environment variables are not duplicated by 'wrap-program' definitions (wrap launched by wrap) and (ii) if the variable is already defined (for non guix reasons), we may want to append the existing value. The only problem I see right now is if a program is launched by a user which does not have $HOME/.guix-profile (like a service). In that case there could be a default profile. This could also serve the second purpose of providing initial default applications (like guix itself!) to all users on guix on distro systems. And on the gnu system, well, there are system installed programs. I guess the above just breaks the functional approach to package management... So probably in the case of the emacs package we should just add libcanberra to its inputs and set the full path in the environment variables. Fede
