Snow-chibi installs SRFI even when Chibi has it

[Retropikzel]

cd /tmp
snow-chibi install --prefix=snow --impls=chibi srfi.39
tree snow/
snow/
└── share
    └── snow
        └── chibi
            └── srfi
                ├── 39.scm
                └── 39.sld

I dont think snow-chibi should install SRFI if implementation already supports it? In this case Chibi also uses SRFI-39 in a way that installing the one from snow-fort will break chibi resulting into this kind of error:

WARNING: exception inside module with no imports - did you forget to (import (scheme base)) in: (scheme base)
ERROR: module attempted to reference itself while loading: (scheme base)
  called from <anonymous> on line 210 of file /usr/local/share/chibi/meta-7.scm
  called from <anonymous> on line 1188 of file /usr/local/share/chibi/init-7.scm
  called from <anonymous> on line 804 of file /usr/local/share/chibi/init-7.scm
  called from error on line 108 of file /usr/local/share/chibi/init-7.scm
  called from for1 on line 81 of file /usr/local/share/chibi/init-7.scm
  called from <anonymous> on line 804 of file /usr/local/share/chibi/init-7.scm
  called from call-with-current-continuation on line 827 of file /usr/local/share/chibi/init-7.scm
  called from <anonymous> on line 259 of file /usr/local/share/chibi/init-7.scm
  called from <anonymous> on line 250 of file /usr/local/share/chibi/meta-7.scm
  called from <anonymous> on line 279 of file /usr/local/share/chibi/init-7.scm
  called from for1 on line 81 of file /usr/local/share/chibi/init-7.scm
  called from for1 on line 81 of file /usr/local/share/chibi/init-7.scm
  called from <anonymous> on line 259 of file /usr/local/share/chibi/init-7.scm
  called from <anonymous> on line 250 of file /usr/local/share/chibi/meta-7.scm
  called from <anonymous> on line 279 of file /usr/local/share/chibi/init-7.scm
  called from for1 on line 81 of file /usr/local/share/chibi/init-7.scm
  called from for1 on line 81 of file /usr/local/share/chibi/init-7.scm
  called from <anonymous> on line 259 of file /usr/local/share/chibi/init-7.scm
  called from <anonymous> on line 250 of file /usr/local/share/chibi/meta-7.scm
  called from <anonymous> on line 437 of file /usr/local/share/chibi/meta-7.scm
  called from <anonymous> on line 1268 of file /usr/local/share/chibi/init-7.scm
  called from <anonymous> on line 800 of file /usr/local/share/chibi/init-7.scm
WARNING: exception inside module with no imports - did you forget to (import (scheme base)) in: (srfi 39)

I can check and fix this with other implementations but I think Chibi is special case on this, so I thought I'd raise an issue.

[Retropikzel]

I think what is doing this is (null? candidates) on this line https://github.com/ashinn/chibi-scheme/blob/master/lib/chibi/snow/commands.scm#L2993

If I have understood correctly this will skip (scheme X) libraries, as they are not in snow-fort. But for example with SRFI-39, which now has package in snow-fort, there are candidates.

If this check is only for (scheme X) and (srfi N) perhaps that check can be removed? I assume there is not situation where library with those names should overwrite implementations libraries.

[ashinn]

I guess this is only broken when using an install prefix? For the local installation it should be consulting the meta files (e.g. /usr/local/share/chibi/.srfi.meta) to see that SRFI 39 is already installed.

So we need to think about how to properly handle this with an install prefix. Just ignoring SRFI's is probably not the right solution because there may be a future SRFI XX with no native Chibi installation which we want to install.

[Retropikzel]

I did a quick test and snow-chibi --impls=kawa srfi-list lists (0 1 2 4 6 8 9 11 13 14 16 17 23 25 26 28 30 35 37 39 41 48 60 64 69 87 95 98 101 197 253) but snow-chibi --impls=kawa install srfi.39 still installs SRFI-39. I commented out the candidates check and it still did the same, so I have propably misunderstood the logic of the code. But the issue is not just with Chibi, and not just with prefix. I'm assuming any SRFI library that is on the implementations SRFI list should not be installed?

[ashinn]

expand-package-dependencies looks up the current installed versions of all dependencies using the installed-libraries function, which references the .meta files. Only if that is not found does it fall back to implementation-supports-natively?, which excludes the R7RS small libraries, the native-srfi-support libraries, and some other special cases.

Note snow-chibi srfi-list doesn't take into account non-native-srfi-support.

[Retropikzel]

Just to make sure I have understood correctly. In the case where native-srfi-support returns 39 in the results SRFI-39 should not be installed? Prefix or no prefix.

[ashinn]

Actually, it looks like the logic might allow you to install SRFI 39 explicitly but not as an implicit dependency.

[ashinn]

... but yes, checking for native-srfi-support is independent of any prefix. Checking for installed libs otherwise (including all SRFIs for Chibi) needs to consult the current installation in the prefix.

[Retropikzel]

Actually, it looks like the logic might allow you to install SRFI 39 explicitly but not as an implicit dependency.

But this is not what is wanted? I'm asking because I would like to fix this, but I want to be 100% certain what is the wanted behaviour (and slight flu makes my head slow too, apologies).

snow-chibi --impls=kawa install srfi.64 installs both SRFI-39 and SRFI-64, and Kawa has both. Same with snow-chibi --impls=sagittarius install srfi.64.

snow-chibi --impls=chibi install srfi.64 does not install either. snow-chibi --impls=chibi --install-prefix=/tmp/snow install srfi.64 installs only SRFI-64, not SRFI-39.

I run into this with automated testing, I would like to run snow-chibi --impls=${SCHEME} install srfi.64 and be confident that if the implementation already has SRFI-39 or/and SRFI-64 they wont be installed, but if it does not they will be. So that I do not need to check which ones have it, and then make if check for each implementation.

[ashinn]

To me intuitively, the logic should be:

1. If not using a prefix, check what is actually available. Don't install SRFI 39 either explicitly or implicitly. Install any non-native SRFI's as requested. We could separately consider a "force" option to install anyway (not in this PR).
2. If using a prefix, check what is already installed in that prefix (and not the host installation), and also assume native Chibi library support (i.e. (scheme *), native SRFI's, (chibi), (chibi ast), ...). However, we don't currently have a concept of native Chibi libraries.

[Retropikzel]

Sounds good. Force option is good for situation where one wants to test SRFI code. I'll start working on this now.