Feature Request: CHIBI_FLAGS

[mnieper]

The chibi-scheme interpreter understands the environment variable CHIBI_MODULE_PATH.

I would like to suggest to add another recognized environment variable, namely CHIBI_FLAGS, which allows setting arbitrary flags. (The flags in CHIBI_FLAGS may be prepended to those given on the command line.)

This can be helpful if, for example, chibi-scheme is run from a script where I cannot (without hacking the script) increase, say, the initial heap size.

[ashinn]

This seems quite dangerous - flag settings can easily break a script. The module path can also break scripts, but is often a necessity, whereas you are discussing an optimization.

I might consider a flag to control just the initial heap size, but the best setting varies per script. I would recommend just editing the script.

[mnieper]

As we are talking about things that are dangerous: The CHIBI_MODULE_PATH contains relative directories by default. In particular, it comes before the system directories. This definitely does break Chibi when I run it in directories with system libraries written for other dialects of Schemes because Chibi tries to load, say, (scheme base), from there first.

I agree that CHIBI_MODULE_PATH is convenient, but a bit more safety, e.g. by lowering its precedence, will be helpful.

[ashinn]

This is an improvement on the previous situation where ./lib and ./ were always included at the start of the system module path.

Generally, if you want to set a custom path you want it to take precedence over the system paths, so lowering the precedence of CHIBI_MODULE_PATH is a bad idea.

And I want to keep it very easy to develop with Chibi, which suggests loading modules from the pwd by default.

So the current state of affairs is convenience by default, but overrideable for security:

# only system paths
CHIBI_MODULE_PATH= chibi-scheme

# only pwd
CHIBI_IGNORE_SYSTEM_PATH=1 chibi-scheme

# only specified paths
CHIBI_IGNORE_SYSTEM_PATH=1 CHIBI_MODULE_PATH=/path/to/mods chibi-scheme

This is at least a step up from many languages which don't provide a secure setting at all.

I suppose we could also provide flags to suppress the system and/or module paths, but you can't specify multiple flags in a #! so that may not be as helpful.

[pclouds]

So the current state of affairs is convenience by default, but overrideable for security:

# only system paths
CHIBI_MODULE_PATH= chibi-scheme

# only pwd
CHIBI_IGNORE_SYSTEM_PATH=1 chibi-scheme

# only specified paths
CHIBI_IGNORE_SYSTEM_PATH=1 CHIBI_MODULE_PATH=/path/to/mods chibi-scheme

Are these documented anywhere? If not and you're not opposed to it, I could add some more in chibi-scheme.1. It does describe CHIBI_MODULE_PATH but not CHIBI_IGNORE_SYSTEM_PATH.

[mnieper]

I agree that it is often convenient to have ./lib and . in the default path. In these cases, however, I usually never want to have the system modules overridden. If I really want this, it makes sense to explicitly ask for it. (At the moment, I cannot use the convenience of CHIBI_MODULE_PATH when there is some, say, scheme/base.sld from some other Scheme floating around.)

I would propose to add CHIBI_SYSTEM_MODULE_PATH, which is, by default, empty. The precedence would then be:

-I > CHIBI_MODULE_SYSTEM_PATH > system paths > CHIBI_MODULE_PATH > -A

[ashinn]

@pclouds, yes, we should add this to the manual.

@mnieper, order really depends on preference, but you absolutely don't need CHIBI_MODULE_SYSTEM_PATH given that we can suppress the system paths and set the exact paths explicitly with CHIBI_MODULE_PATH.

And setting CHIBI_MODULE_PATH= is exactly how you avoid the problem of an unwanted scheme/base.sld.

[mnieper]

Am Di., 29. Sept. 2020 um 14:40 Uhr schrieb Alex Shinn < notifications@github.com>:

@pclouds https://github.com/pclouds, yes, we should add this to the manual.

@mnieper https://github.com/mnieper, order really depends on preference, but you absolutely don't need CHIBI_MODULE_SYSTEM_PATH given that we can suppress the system paths and set the exact paths explicitly with CHIBI_MODULE_PATH.

And setting CHIBI_MODULE_PATH= is exactly how you avoid the problem of an unwanted scheme/base.sld.

Which I have been doing. But it forces me to add "-A ." so that the convenience this all is about is doubly lost.

The current behavior only makes sense when you want more often override system libraries silently than not.

[ashinn]

I'm on the fence about the order of "system paths" vs CHIBI_MODULE_PATH, since these include snow packages and third party installs.

[mnieper]

For which, in some sense, the same argument applies as to the system modules. For example, I have srfi/8.sld in my src/ directory for my Unsyntax project. It includes non-portable code because it just has to be understood by my expander. If SRFI 8 were installed on my Chibi-Scheme as a snow package, I still don't want to have it overridden.

Of course, for the developer of such a SRFI 8 snow package, it will become a bit more inconvenient because they would have to explicitly include the path (as otherwise they would just test the installed version).

It's hard to find an optimal solution. But let me add one more situation, to which silent substitution of system-wide installed packages can lead: Chibi's SRFI 128 just reexports SRFI 69's hash-table-ref. For this, it relies on its own implementation of SRFI 69, which exports an extended hash-table-ref that is already SRFI 128 compatible. So things will break if some has some other version of SRFI 69 in their module path. Sometimes, you may want this, but I am still thinking that explicit is better than implicit here.

[ashinn]

Note I've switched the order of system and user module paths, which I think satisfies everything in the path handling.

I'm still considering an env var for preferred heap size.