Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

[Christopher Allan Webber]

[-- Attachment #1: Type: text/plain, Size: 2657 bytes --]

Hello all,

Since 8sync became a GNU project (yay!) I figured I should actually put
a website together, and well... what better time to bust out Haunt?

I wanted to make use of the Skribe reader, so I figured I'd make use of
guix environment.  Unfortunately, the file I put together doesn't work.
The puzzling part?  Even though $PATH is propagated, $GUILE_LOAD_PATH is
not!

  bash-4.3$ guix environment -l guix.scm --pure
  bash-4.3$ haunt build
  Backtrace:
  3598: 2 [#<procedure 25b1d00 at ice-9/boot-9.scm:3597:25 (mif-args)> ((haunt ui))]
  2867: 1 [resolve-interface (haunt ui) #:select ...]
  In unknown file:
     ?: 0 [scm-error misc-error #f "~A ~S" ("no code for module" (haunt ui)) #f]
  
  ERROR: In procedure scm-error:
  ERROR: no code for module (haunt ui)
  
  bash-4.3$ echo $PATH
  /gnu/store/0m1wh7i21w6x6agjard3x1bd53y6h1b4-tar-1.28/bin:/gnu/store/8qcqrz4r483vbcbwx5xzy11kdkxqv0c8-gzip-1.6/bin:/gnu/store/mpgci6nb800ckc8cyi3vhm9i8h17zm2l-bzip2-1.0.6/bin:/gnu/store/kz4vzwnm7vdnxbfb3ygc91iv68rjsfmm-xz-5.2.2/bin:/gnu/store/iw4xjh2fx7lbil7m7yghz7yyrf6ks8pq-file-5.25/bin:/gnu/store/gg7yl3al4ms4p9z67k1r7k0jn918l864-diffutils-3.3/bin:/gnu/store/1g9bd3ccfpslgirikaw7wcdrspavz2xz-patch-2.7.5/bin:/gnu/store/4jmy669vqj2zkz03z6jrk26if2y2m6ad-sed-4.2.2/bin:/gnu/store/z6780v4ix4h1id452gnhl9p15rl3rx9y-findutils-4.6.0/bin:/gnu/store/c2ci62qwp62rcpbh9qgmmlyvgszvf8yn-gawk-4.1.3/bin:/gnu/store/iy9a4pk184ipkd470rvssx26rrnl2c5c-grep-2.22/bin:/gnu/store/wczs2ckr8y0m79h3nl199lx85vmidga3-coreutils-8.24/bin:/gnu/store/l1iq0lhklsiw7q7jhlw9cgdkcm6axd38-make-4.1/bin:/gnu/store/l7px210li6zviymgvp3cps6n48x7fgpl-bash-4.3.42/bin:/gnu/store/agnxzx1yza8ci0a1gz5pds8gdg8qmnz5-ld-wrapper-0/bin:/gnu/store/dki0v5cvf1mhfz571k622xvzi1nyinl2-binutils-2.25.1/bin:/gnu/store/gz9h7bicwcx3qbvnp0xgpvh50q5l104b-gcc-4.9.3/bin:/gnu/store/gybk6iz6n659njzg56vqsy5bg7irk370-glibc-2.22/bin:/gnu/store/gybk6iz6n659njzg56vqsy5bg7irk370-glibc-2.22/sbin:/gnu/store/0sb1rkqbyj2ys7f9w48kxlhalg1qz5l3-haunt-0.1/bin:/home/cwebber/bin:/home/cwebber/.gem/ruby/1.8/bin:/home/cwebber/.local/bin:/home/cwebber/.cabal/bin
  bash-4.3$ echo $GUILE_LOAD_PATH
  
  bash-4.3$ 

(... yeah I know I ought to remove that PATH modification stuff from my
.bashrc ...)

The funny thing is, if I do the same with Sly's guix.scm, everything
works well:

bash-4.3$ guix environment -l guix.scm --pure
bash-4.3$ echo $GUILE_LOAD_PATH
/gnu/store/l3flpq5s2wyvyqdwi7y1qzcmdy1h878h-guile-sdl2-0.1.0/share/guile/site/2.0:/gnu/store/l5b4ny6288f2xbd5cl211s3jcy87sj99-guile-opengl-0.1.0/share/guile/site/2.0

So maybe I'm doing something wrong?  Ideas?  File attached!


[-- Attachment #2: guix.scm --]
[-- Type: application/octet-stream, Size: 2595 bytes --]

;;; Haunt --- Static site generator for GNU Guile
;;; Copyright © 2015 David Thompson <davet@gnu.org>
;;;
;;; This file is part of Haunt.
;;;
;;; Haunt is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or
;;; (at your option) any later version.
;;;
;;; Haunt is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;;; General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with Haunt.  If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:
;;
;; GNU Guix development package.  To build and install, run:
;;
;;   guix package -f guix.scm
;;
;; To use as the basis for a development environment, run:
;;
;;   guix environment -l guix.scm
;;
;;; Code:

(use-modules (guix packages)
             (guix licenses)
             (guix git-download)
             (guix build-system gnu)
             (gnu packages)
             (gnu packages autotools)
             (gnu packages guile)
             (gnu packages texinfo))

(define haunt-from-git
  (package
    (name "haunt")
    (version "0.1")
    (source (origin
              (method git-fetch)
              (uri (git-reference
                    (url "git://dthompson.us/haunt.git")
                    (commit "5b09c3c")))
              (sha256
               (base32
                "1vhrwa8r2gb0jck7d6bj7bx3dazpapw2399q0sh8g8i7hs06kcyx"))))
    (build-system gnu-build-system)
    (arguments
     '(#:phases
       (modify-phases %standard-phases
         (add-after 'unpack 'bootstrap
           (lambda _ (zero? (system* "sh" "bootstrap")))))))
    (native-inputs
     `(("autoconf" ,autoconf)
       ("automake" ,automake)
       ("texinfo" ,texinfo)))
    (inputs
     `(("guile" ,guile-2.0)))
    (propagated-inputs
     `(("guile-reader" ,guile-reader)))
    (synopsis "Functional static site generator")
    (description "Haunt is a static site generator written in Guile
Scheme.  Haunt features a functional build system and an extensible
interface for reading articles in any format.")
    (home-page "http://haunt.dthompson.us")
    (license gpl3+)))


(package
  (name "8sync-website")
  (version "git")
  (source #f)
  (build-system gnu-build-system)
  (synopsis #f)
  (description #f)
  (license #f)
  (home-page #f)
  (propagated-inputs
   `(("haunt" ,haunt-from-git))))

Re: Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

[Christopher Allan Webber]

Just for posterity, Dave helped me figure out what was wrong.  I missed
putting guile-2.0 in my inputs.  Critical!  Well, once I did that,
things were fine!

Re: Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

[Ludovic Courtès]

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> Just for posterity, Dave helped me figure out what was wrong.  I missed
> putting guile-2.0 in my inputs.  Critical!  Well, once I did that,
> things were fine!

Indeed.  However, since Haunt ships a command-line tool, we should fix
the Haunt package in Guix to wrap ‘bin/haunt’ such that the tool has
GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly set.

Done in 4ecbf6d.  I think it should be fixed upstream though.  :-)

BTW, ‘guix build haunt --with-input=guile=guile-next’ fails at configure
time (it insists on 2.0.)

Ludo’.

Re: Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

[Thompson, David]

On Wed, Feb 10, 2016 at 9:17 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>
>> Just for posterity, Dave helped me figure out what was wrong.  I missed
>> putting guile-2.0 in my inputs.  Critical!  Well, once I did that,
>> things were fine!
>
> Indeed.  However, since Haunt ships a command-line tool, we should fix
> the Haunt package in Guix to wrap ‘bin/haunt’ such that the tool has
> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly set.
>
> Done in 4ecbf6d.  I think it should be fixed upstream though.  :-)

I don't understand why this would require an upstream fix for what
seems to be a Guix-specific quirk.  Could you elaborate?

> BTW, ‘guix build haunt --with-input=guile=guile-next’ fails at configure
> time (it insists on 2.0.)

Thanks, Ludo.  I noticed that in another project of mine.  I guess I'm
using the wrong autoconf macro to check for the version being greater
than 2.0.x.  I'll have to figure out what the correct thing is.

- Dave

Re: Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Wed, Feb 10, 2016 at 9:17 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>>
>>> Just for posterity, Dave helped me figure out what was wrong.  I missed
>>> putting guile-2.0 in my inputs.  Critical!  Well, once I did that,
>>> things were fine!
>>
>> Indeed.  However, since Haunt ships a command-line tool, we should fix
>> the Haunt package in Guix to wrap ‘bin/haunt’ such that the tool has
>> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly set.
>>
>> Done in 4ecbf6d.  I think it should be fixed upstream though.  :-)
>
> I don't understand why this would require an upstream fix for what
> seems to be a Guix-specific quirk.  Could you elaborate?

I think stand-alone commands like ‘haunt’ should ensure that they’ll
find their modules rather than assume that the user defined
‘GUILE_LOAD_PATH’ & co. appropriately.

This is particularly important when users are likely to use exclusively
the CLI (the same is also true of ‘skribilo’, ‘guix’, ‘herd’, etc.)

Ludo’.

Re: Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

[Thompson, David]

On Thu, Feb 11, 2016 at 5:40 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Wed, Feb 10, 2016 at 9:17 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>>>
>>>> Just for posterity, Dave helped me figure out what was wrong.  I missed
>>>> putting guile-2.0 in my inputs.  Critical!  Well, once I did that,
>>>> things were fine!
>>>
>>> Indeed.  However, since Haunt ships a command-line tool, we should fix
>>> the Haunt package in Guix to wrap ‘bin/haunt’ such that the tool has
>>> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly set.
>>>
>>> Done in 4ecbf6d.  I think it should be fixed upstream though.  :-)
>>
>> I don't understand why this would require an upstream fix for what
>> seems to be a Guix-specific quirk.  Could you elaborate?
>
> I think stand-alone commands like ‘haunt’ should ensure that they’ll
> find their modules rather than assume that the user defined
> ‘GUILE_LOAD_PATH’ & co. appropriately.
>
> This is particularly important when users are likely to use exclusively
> the CLI (the same is also true of ‘skribilo’, ‘guix’, ‘herd’, etc.)

Thanks for the explanation, I am convinced and will (eventually) fix
in Haunt and my other Guile applications.  Does this also apply to the
applications dependencies, or just the modules for itself?  If the
former, I'm actually not sure how to do the relevant autotools magic
to make it work.

- Dave

Re: Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

[Christopher Allan Webber]

Thompson, David writes:

> On Thu, Feb 11, 2016 at 5:40 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>
>>> On Wed, Feb 10, 2016 at 9:17 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>>>>
>>>>> Just for posterity, Dave helped me figure out what was wrong.  I missed
>>>>> putting guile-2.0 in my inputs.  Critical!  Well, once I did that,
>>>>> things were fine!
>>>>
>>>> Indeed.  However, since Haunt ships a command-line tool, we should fix
>>>> the Haunt package in Guix to wrap ‘bin/haunt’ such that the tool has
>>>> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly set.
>>>>
>>>> Done in 4ecbf6d.  I think it should be fixed upstream though.  :-)
>>>
>>> I don't understand why this would require an upstream fix for what
>>> seems to be a Guix-specific quirk.  Could you elaborate?
>>
>> I think stand-alone commands like ‘haunt’ should ensure that they’ll
>> find their modules rather than assume that the user defined
>> ‘GUILE_LOAD_PATH’ & co. appropriately.
>>
>> This is particularly important when users are likely to use exclusively
>> the CLI (the same is also true of ‘skribilo’, ‘guix’, ‘herd’, etc.)
>
> Thanks for the explanation, I am convinced and will (eventually) fix
> in Haunt and my other Guile applications.  Does this also apply to the
> applications dependencies, or just the modules for itself?  If the
> former, I'm actually not sure how to do the relevant autotools magic
> to make it work.
>
> - Dave

Okay, so I'm less convinced!  I was thinking about this on my walk.
Maybe I have something wrong though... would this also prevent loading
other Guile modules when running "haunt build" that weren't inputs, or
would it just guarantee that inputs are preferred?

If the former, a-ok.  If the latter, I am worried: this seems like it
could block important late-binding use cases.  Eg, if I build a library
of Haunt utilities I use across all my Haunt sites and call it
haunted-house, will I be able to (use-modules (haunted-house)) still?
(Or maybe I'd want to import a new external reader, etc.)

If so, then no worries.  If not, that's a worry.  It'd also be a worry
in a project like MediaGoblin, where a user might install a plugin for a
new media type outside of MediaGoblin.  If they "launch" mediagoblin
through some gmg executable, and I took the method above, could they
still find a plugin which wasn't an input on the path?

(If the above worries are unfounded, then great!)

Re: Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Thu, Feb 11, 2016 at 5:40 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>
>>> On Wed, Feb 10, 2016 at 9:17 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>>>>
>>>>> Just for posterity, Dave helped me figure out what was wrong.  I missed
>>>>> putting guile-2.0 in my inputs.  Critical!  Well, once I did that,
>>>>> things were fine!
>>>>
>>>> Indeed.  However, since Haunt ships a command-line tool, we should fix
>>>> the Haunt package in Guix to wrap ‘bin/haunt’ such that the tool has
>>>> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly set.
>>>>
>>>> Done in 4ecbf6d.  I think it should be fixed upstream though.  :-)
>>>
>>> I don't understand why this would require an upstream fix for what
>>> seems to be a Guix-specific quirk.  Could you elaborate?
>>
>> I think stand-alone commands like ‘haunt’ should ensure that they’ll
>> find their modules rather than assume that the user defined
>> ‘GUILE_LOAD_PATH’ & co. appropriately.
>>
>> This is particularly important when users are likely to use exclusively
>> the CLI (the same is also true of ‘skribilo’, ‘guix’, ‘herd’, etc.)
>
> Thanks for the explanation, I am convinced and will (eventually) fix
> in Haunt and my other Guile applications.  Does this also apply to the
> applications dependencies, or just the modules for itself?

I would include dependencies as well.

To draw a parallel, when I type ‘ls’, I’m happy it doesn’t expect me to
have libc, libcap, and libattr in $LD_LIBRARY_PATH.

> If the former, I'm actually not sure how to do the relevant autotools
> magic to make it work.

Hopefully there are several examples you could borrow from.  :-)

Cheers,
Ludo’.