curvc does not find std.curv

[sebastien]

In my setup I symlinked curvcusing ln -sfr from curv's build path ~/.local/src/curv/release/curvc, howerver it seems that instead of using the canonical path as a root for the executable, boost uses the symlink's path:

{"error":{"message":"boost::filesystem::canonical: No such file or directory: \"/home/sebastien/.local/bin/../lib/std.curv\""}}

If it's not possible to correct that behaviour, would it be possible to use a CURV_PATH environment variable to indicate where the library is supposed to be found? In the meantime, I'll use a shell script that forwards arguments.

[doug-moen]

I have confirmed the bug. Now considering how to fix the code.

[doug-moen]

Seems to work now. Let me know if there is a problem.

[sebastien]

Hmm, still not working for me with 6bdaadc93b553545e3c925358ea673b58011925d.

$ curvc /dev/null  
{"error":{"message":"boost::filesystem::canonical: No such file or directory: \"/home/sebastien/Workspace/curved/bin/../lib/std.curv\""}}

I did a make clean just to be sure.

[sebastien]

Also, in general it might be good to have a $CURV_PATH, but that might be a separate ticket. Another suggestion is that instead of using lib/std.curv to use lib/curv/std.curv so that every curv lib nicely fits into a curv directory. Right now, curved lib dir has the following entries: components css fonts glsl images js pages pcss py sjs xsl so I could just put a curv directory in there.

[doug-moen]

When I tested this bug fix on Ubuntu, using bash, I had a weird problem. When invoking curvc via the shell command $PATH, I kept getting the old version of the program. I think bash was caching the path to the old version of the executable. When I started a new bash shell, then without any other change, the curvc command from the bash prompt was now using my symlink and running the correct version of the program, and then I verified that the bug fix worked.

I can add the environment variable $CURV_LIBDIR to curvc.
That is the directory that currently contains std.curv, plus curv/*.curv (the library files accessed using lib). This directory normally resolves to /usr/local/lib in a Curv installation.

I agree that a different directory structure would make more sense. How about this:

$CURV_LIBDIR, which normally resolves to /usr/local/lib/curv, is a directory contains std.curv and lib/*.curv (the latter are collectively the lib files).

[sebastien]

I'd probably recommend $CURV_PATH instead. In Python, it's $PYTHONPATH, in Go it's $GOPATH, in Ruby it's $GEM_PATH, etc. Later, you might want to have more than one path to resolve the libraries.

And BTW it works now, I think I had another version in my $PATH when I tested. Thanks for the quick fix!

[doug-moen]

$PYTHONPATH is a search path. It is a colon-separated list of directories, similar to $PATH.
$GOPATH is also a search path.
$GEM_PATH is also a search path.

Search paths are one possible design for how a package manager finds a named package. I do not want to use that design for package management in Curv. I don't want a CURV_PATH.

I will close this bug, since the problem is resolved. Open another issue if you later want an environment variable.