Hi,

could you please review patch to fix a likely regression issue where the
testrunner couldn't handle relative paths in `sys.path`. It fixes #1204.

This is likely a regression from #1176, where the update to the new
module loading system caused relative paths to never match a fully
qualified module name. The patch now expands relative paths to their
absolute form before comparing them to the module path.

This issue was breaking the vanilla `basilisp test` command, as it adds
an empty string (`""`) entry to `sys.path`, which is interpreted as
`"."`. Since this is a relative path, it wasn’t handled by the logic,
causing the project directory not to be recognized as the root of the
Basilisp test modules.

I’ve added a test that invokes `basilisp test` directly as a subprocess.
Unfortunately, I couldn’t find a way to control the pytester `sys.path`
entries with the precise control required for this test. Any counter
suggestions are most welcome.

Thanks

---------

Co-authored-by: ikappaki <ikappaki@users.noreply.github.com>

Fixes #1202

…1211)

Hi,

could you please review patch to pickup the boostrap site-packages
location from the `sysconfig` `purelib` path. It fixes #1208.

The bootstrap options and code now operate on a single path instead of a
list, likely because `getsitepackages` previously returned a list of
paths, which is no longer relevant (unless there's another reason I'm
missing).

I've also updated the `bootstrap` command to print the file's creation
path, which I find useful for awareness.

For testing, I couldn't think of a case other than creating a virtual
environment to test the `bootstrap` within it. I implemented a minimal
solution using the `pytest_virtualenv` plugin, which provides a fixture
for this. Since creating a Basilisp environment takes 20+ seconds, I
added a pytest decorator to run it only on GitHub CI. Let me know if you
have other testing suggestions or if it's better to leave this out
altogether. I consider these type of tests as part of integration
testing (which ideally run as a separate command/job), but we don't have
that setup (yet?).

Thanks

---------

Co-authored-by: ikappaki <ikappaki@users.noreply.github.com>