Split out from #904, which is the first bug this blind spot hid.
Correction to the original framing of this issue. I first wrote that no CI
leg runs an install. That is wrong: install-smoke (.github/workflows/ci.yml)
runs ./install.sh, which builds src/eigenscript in the tree and copies the
stdlib to ~/.local/lib/eigenscript. So the leg produces exactly the
configuration a contributor has after following the README — and exactly the one
that forked import resolution in #904: two stdlibs, the bare <name>.eigs probe
answering from the install root while lib/<name>.eigs answers from the tree.
The gap is sharper than "no install leg", and more interesting: the
configuration existed in CI and nothing looked at it. The job's only assertions
were test -x on two binaries and --version, which imports nothing. So the
runner sat in the broken state and reported green.
#906 adds the missing look — a stdlib import from both the installed binary and
the tree binary, asserting the module resolves with no shadowing warning. It
fails on the pre-fix binary.
What is still unexercised
The install leg now covers import resolution. It still never runs:
A cheap next step would be running a subset of the suite on the
install-smoke runner after install.sh — the sections that touch module
resolution and bundles — rather than a second full-suite leg.
The general form
CI is a consistency check on one configuration. Where a second configuration
already exists in CI, the cost of asserting something about it is a few lines;
the cost of not asserting is that it silently certifies the broken state. #904
was found on a second machine, not here, while the runner that could have found
it was passing.
Split out from #904, which is the first bug this blind spot hid.
Correction to the original framing of this issue. I first wrote that no CI
leg runs an install. That is wrong:
install-smoke(.github/workflows/ci.yml)runs
./install.sh, which buildssrc/eigenscriptin the tree and copies thestdlib to
~/.local/lib/eigenscript. So the leg produces exactly theconfiguration a contributor has after following the README — and exactly the one
that forked import resolution in #904: two stdlibs, the bare
<name>.eigsprobeanswering from the install root while
lib/<name>.eigsanswers from the tree.The gap is sharper than "no install leg", and more interesting: the
configuration existed in CI and nothing looked at it. The job's only assertions
were
test -xon two binaries and--version, which imports nothing. So therunner sat in the broken state and reported green.
#906 adds the missing look — a stdlib import from both the installed binary and
the tree binary, asserting the module resolves with no shadowing warning. It
fails on the pre-fix binary.
What is still unexercised
The install leg now covers import resolution. It still never runs:
importwarns, and the installed copy wins over the binary's own stdlib (and over a bundle's extracted lib/) #904 were suitefailures; the leg would not have shown them even with the new step, only the
one import)
eigenlsp/eigsdapdoing anything beyond existing on PATH--api, whose stdlib index walks the same candidate lib dirs the resolverdoes (
lib_candidate_dirsinsrc/lint.c) and has the same two-rootambiguity
A cheap next step would be running a subset of the suite on the
install-smokerunner afterinstall.sh— the sections that touch moduleresolution and bundles — rather than a second full-suite leg.
The general form
CI is a consistency check on one configuration. Where a second configuration
already exists in CI, the cost of asserting something about it is a few lines;
the cost of not asserting is that it silently certifies the broken state. #904
was found on a second machine, not here, while the runner that could have found
it was passing.