Environments like Python

[dougransom]

I think it would be cool to have environments similar to the way Python virtual environments work. The environment would potentially comprise:

• a path to system-supplied prolog files, copied from the prolog install or some other place specified when the environment is created.
  -a path to installed prolog files, installed with a tool like pip. like pip, editable installs would add source directories into this list that the user is working on in their workspace. so something like 'scryer install ." would add the current folder into prolog search path. 'scryer install https://github.com/mthom/scryer-shen.git' would install from github.
• maybe a path to .scryerrc for intialisation.

[jjtolton]

From experience I have observed that if this isn't done by the language, it will be done by the users at some point. That's good on the one hand but also it can lead to fragmentation and other issues.

[hurufu]

Currently all libraries are baked into scryer-prolog executable, so there is no need for virtual envs like for Python.

[bakaq]

What about 3rd party libraries? Scryer Prolog already has some of those like djota, postgresql-prolog and constrained.pl. Currently you need to do the package management and wiring manually.

[jjtolton]

From a hacker perspective, one interesting thought with the advent of the shared library -- since Scryer will be expose FFI bindings and be able to consume them -- is "scryer-in-scryer"! The shared library lets you easily spin up and configure WAM instances, and passing data from Scryer to Scryer seems like it should be very natural. This would also put environment management as a pure Prolog concern!

That's how I would do it, anyway. 😎 See point above about user fragmentation 🤣

[bakaq]

I personally really don't like how pip (and most other 352 Python package managers) do package management and environments. I think if we eventually do this we should do something closer to npm (Javascript), cargo (Rust) and poetry (Python). That is, having dependencies local to the project, lockfiles (!!!!!), and maybe not even having a "global environment". I think editable installs are also unnecessary, because Scryer Prolog currently doesn't compile anything (unlike Python wheels) and just runs from source.

I think basic support for something like this could be added by having an cli option to add "library paths" and make them available to use as library(name). Example of how it would work:

$ ls
program.pl  scryer_modules
$ ls scryer_modules/
example_lib.pl
$ cat program.pl 
:- use_module(library(example_lib)).

main :-
    example("hello"),
    halt.

:- initialization(main).
$ cat scryer_modules/example_lib.pl 
:- module(example_lib, [example/1]).

:- use_module(library(format)).

example(X) :- portray_clause(X).
$ scryer-prolog -L scryer_modules program.pl
"hello".

A limited npm-like package manager could be built based on that.

[triska]

Please also see this related issue: #701

[hurufu]

Rudimentary form of what is described here can already be implemented. Place the following into your .scryerrc:

use_custom_modules(Ms) :-
    getenv("SCRYER_LIBRARY_PATH", LD),
    setup_call_cleanup(
        working_directory(WD, LD),
        maplist(use_module, Ms),
        working_directory(_, WD)
    ).

Then just start Scryer with modified environment:

export SCRYER_LIBRARY_PATH=~/.scryer
scryer-prolog -g 'use_custom_modules([foo,bar,baz])'

Alternatively you can load them in the top-level:

?- use_custom_modules([foo,bar,baz]).

[hurufu]

Sadly my previous approach is hardly usable, because initialization goals are executed before ~/.scryerrc is read, so this snippet always fails:

:- initialization(use_custom_modules([foo,bar,baz]).

Another approach:

scryer-prolog -g 'use_custom_modules([foo,bar,baz]).' my_program.pl

doesn't work too, because my_program.pl is consulted before goal in the command line is executed. It fails if I need custom operators.

Very sad, that means that I still need to specify all local modules using full path.

[triska]

because initialization goals are executed before ~/.scryerrc is read

Could you please double-check this and file an issue if this is the case? I made a quick test, and from what I saw, initialization/1 directives in ~/.scryerrc are executed before initialization/1 directives in any loaded files, which is also my expectation for how this should work. Please file any unexpected behaviour as an issue!

[hurufu]

I've created issue #2560 for that. I was wrong in my previous comment, it fails for a different reason.