Change importlib to first try to import modules using the standard mechanism #11997

nicoddemus · 2024-02-17T16:26:01Z

As detailed in #11475 (comment), currently with --import-mode=importlib pytest will try to import every file by using a unique module name, regardless if that module could be imported using the normal import mechanism without touching sys.path.

This has the consequence that non-test modules available in sys.path (via other mechanism, such as being installed into a virtualenv, PYTHONPATH, etc) would end up being imported as standalone modules, instead of imported with their expected module names.

To illustrate:

.env/
  lib/
    site-packages/
      anndata/
        core.py

Given anndata is installed into the virtual environment, python -c "import anndata.core" works, but pytest with importlib mode would import that module as a standalone module named ".env.lib.site-packages.anndata.core", because importlib module was designed to import test files which are not reachable from sys.path, but now it is clear that normal modules should be imported using the standard mechanisms if possible.

Now imporlib mode will first try to import the module normally, without changing sys.path, and if that fails it falls back to importing the module as a standalone module.

This supersedes #11931.

Fix #11475
Close #11931

testing/test_pathlib.py

nicoddemus · 2024-02-17T20:13:44Z

@flying-sheep I believe the changes here are the correct approach for the importlib in general. With this PR the tests in your pytest-doctest-import-mismatch pass (including the doctest), the only change being required is to also exclude the conftest.py from being installed -- it should always be located near the test files, as the fixtures defined in conftest.py files are only available for tests in the same directory or below.

src/_pytest/pathlib.py

nicoddemus · 2024-02-18T12:13:23Z

@flying-sheep would appreciate if you can test this PR using your original project to ensure it works as intended (if it is simple and you have the time, of course). 👍

flying-sheep

Beautiful! If I understand correctly, this is basically the more efficient way to do what I did in my PR by brute forcing. I have a thought regarding the changed wording for --import-mode=importlib:

doc/en/explanation/pythonpath.rst

nicoddemus · 2024-02-18T12:34:11Z

Beautiful! If I understand correctly, this is basically the more efficient way to do what I did in my PR by brute forcing.

Indeed. The previous semantics were:

Ignore sys.path entirely, and try to import everything by importing it directly, deriving a unique module name.

This has now changed to:

Try to import the path normally with the current sys.path. If that fails, import it directly deriving a unique module name.

In retrospect this is what we should have implemented since the beginning, but the thought when this was initially implemented was that it would be used to import test modules only, but we missed the case of importing normal modules too (for doctesting for example).

flying-sheep · 2024-02-18T12:45:24Z

we missed the case of importing normal modules too (for doctesting for example).

An alternative way of solving this would have been to only collect doctests from roots using --pyargs, then always use sys.path for importing the doctests’ parent modules. But that ship has sailed I guess.

Thank you for spending time solving this!

flying-sheep · 2024-02-18T13:18:16Z

I tested this with our package, and it seems to indeed work flawlessly!

nicoddemus · 2024-02-18T13:19:58Z

An alternative way of solving this would have been to only collect doctests from roots using --pyargs, then always use sys.path for importing the doctests’ parent modules. But that ship has sailed I guess.

That would solve doctests, but I think the problem is more general and best solved in import_path directly, so any code importing a module will have the same behavior.

I tested this with our package, and it seems to indeed work flawlessly!

Thanks!

bluetech · 2024-02-18T15:05:51Z

I haven't reviewed the changes yet, but regarding

Now imporlib mode will first try to import the module normally, without changing sys.path, and if that fails it falls back to importing the module as a standalone module.

Just to make sure, IIRC one of the reasons for adding importlib mode was to deal with the non-package-conftest problem where it's like

a/conftest.py
b/conftest.py

and then we try to load conftest module twice. Or it may be not with conftest but something similar, hopefully you get the idea.

If so, doesn't "first try to import the module normally" still run into a problem here, that a module with the same name but different path is already loaded, and we'll return it?

nicoddemus · 2024-02-18T15:14:18Z

If so, doesn't "first try to import the module normally" still run into a problem here, that a module with the same name but different path is already loaded, and we'll return it?

Assuming tests is at the root of the repository and is not importable:

tests/
  a/
    conftest.py
  b/
    conftest.py

Here we will try to import tests/a/conftest.py and it will fail, so we fallback to import this module directly using importlib.import_module and derive a new name for it based on the rootdir: tests.a.conftest. Same for b/conftest.py, so they will end up with different module names and everything will work.

I will improve the tests to also cover this scenario so there is no doubt this works as intended.

nicoddemus · 2024-02-18T16:05:28Z

Hmm I realize now probably the wording "standalone" is confusing; I meant "not part of a package", but I can see that one can understands this as "using the module's base name only".

Appreciate any suggestions.

bluetech

The import_module might import (= execute) modules that were not intended. I don't think that we can assume that arbitrary names (names of test files) are safe to import.

E.g. consider I'm running pytest x.py and I have an x module in my site-packages, then the x module in site-packages will get executed, this is quite unexpected and possibly dangerous. (The code as written also has a bug, where even in the case the if mod.__file__ and Path(mod.__file__) == path condition is false, the module from the site-packages will still be returned, because of the return sys.modules[module_name] just below).

The Python importlib stuff confuses me greatly but it seems to me that the existing importlib mode code basically has the right idea -- it first finds the module spec and only executes it afterwards. Perhaps we can just tweak/extend the existing sys.meta_path search code to work, and keep something like the mod.__file__ and Path(mod.__file__) == path check, but with the module spec, not the actual module?

nicoddemus · 2024-02-18T18:39:29Z

E.g. consider I'm running pytest x.py and I have an x module in my site-packages, then the x module in site-packages will get executed, this is quite unexpected and possibly dangerous

Ouch, you are definitely right. Will have to think about this some more then.

nicoddemus · 2024-02-18T18:41:05Z

(The code as written also has a bug, where even in the case the if mod.file and Path(mod.file) == path condition is false, the module from the site-packages will still be returned, because of the return sys.modules[module_name] just below).

Note that the module_name will be different, not the one we tried originally before the check.

nicoddemus · 2024-02-18T20:12:42Z

E.g. consider I'm running pytest x.py and I have an x module in my site-packages, then the x module in site-packages will get executed, this is quite unexpected and possibly dangerous

Great catch here @bluetech, I really dropped the ball on this one. 😓

Using the specs for that first import, which crucially also uses the module location to import the file and not only the bare module name as my previous attempt, nicely solves this.

I added another test to ensure we are covering the situation you described, where pytest /path/to/x.py will only import /path/to/x.py, not some other x.py that just happens to be reachable from sys.path.

testing/test_doctest.py

src/_pytest/pathlib.py

bluetech

Didn't review yet, only looked at the resolve_pkg_root_and_module_name function.

src/_pytest/pathlib.py

bluetech · 2024-02-19T07:24:17Z

src/_pytest/pathlib.py

+
+    Passing the full path to `models.py` will yield Path("src") and "app.core.models".
+
+    If consider_ns_packages is True, then we additionally check if the top-level directory


IIUC, this handles the case where there is a python package (directory structure with __init__.py, like app above, and not a single file) nested inside a namespace package (like let's say mycompany). I have two questions/comments:

Why only handle python packages (__init__.py) and not the case where app.core.models doesn't have __init__.py's either?

Namespace packages can have multiple levels, e.g. com.mycompany.app.core.models not just mycompany.app.core.models. IIUC the current code only handles one level.

Yeah that's something we can revisit later, pytest never supported packages without a __init__ correctly (is there a name for it?), I recall we had several discussions with other package-related authors (pip maintainers, Jason Coombs, etc) on how to support that, but the discussion stalled. I would be happy to tackle that in a separate PR though, as this requires more tests in order to make sure the support is sound.

Do they? I always thought it was a mechanism just to share the top-level, based on the use cases out there and the docs at https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages. I will double check if this is really supported, and if so update the code accordingly.

About 2, you are right, it does support multiple levels (TIL). 👍

I'm hesitant on adding multiple level support for namespace packages, let me explain my reasoning.

I can see situations (might be contrived I admit) where we identify a module as part of a namespace package incorrectly, just because the directory is in sys.path somehow.

For example:

temp/ some/ folder/ myproject/ src/ com/ company/ myapp/ __init__.py core.py

If we look upwards from core.py in order to find if it is in a namespace package, we must keep looking upwards until we find a directory in sys.path or until we reach the root of the file system and give up. Suppose for some reason temp/ is in sys.path (possibly due to a misconfiguration), this means we could end up determining that core.py is be part of the package temp.some.folder.myproject.src.com.company.myapp.core, which is incorrect, depending on the order directories appear in sys.path, if temp/ appears first: temp/ or temp/some/folder/myproject/src.

The namespace package rules are easy to follow when you try to figure out a file path starting from a module name: to see if com.company.myapp.core as it appears in the source code is valid , we need to through each sys.path entry, join it with com/company/myapp/core.py and see if the file exists: if it does, double check that there are no __init__.py files present, then import it. This is what Python needs to do and why it works unambiguously.

But the situation is not so simple when you need to derive a module name starting from a file path, because you need to search recursively upwards and see if you can build a valid module name using that full path, but even if we do build a valid module name we don't know if that was intentional or not, and we might end up with a module named temp.some.folder.myproject.src.com.company.myapp.core; in the previous case, going from module name to path, the user is telling us the module name, so there is no ambiguity.

I recall that was the central point when this matter was being discussed with other package-related authors in the past (I cannot find the thread, perhaps @RonnyPfannschmidt can recall at least which forum that took place?).

Hope I was able to explain the situation, sorry if the explanation is lacking.

Btw, I only introduced this change regarding namespace packages because 1 specific test in doctests that is meant to import from namespace packages, but AFAICT it was working with namespace packages by accident, due to how we were building the module name from the path, not due to any proper namespace package support -- so much that I changed it slighly the test to use a src layout, while keeping the namespace package configuration, and then the code in main could not find it anymore. The change implemented here made we at least recognize namespace packages with one level.

I might be overthinking this too, so would like to hear your opinions on this.

Unless my assessment is incorrect, I think a compromise would be to:

Support just one level for now; up until now we did not support any level at all, so this is a small test to provide full support.

Keep the status quo of "pytest does not yet support namespace packages", remove the partial support I added here, and mark the test as xfail.

Implement full support in this PR.

I'm OK with 3), just wanted to present the full picture and see if this is the direction we want to go.

There might also a simpler/safer way to determine if a file path is part of a full namespace package that I'm not seeing, in which case much of my concerns here are moot.

To aid in the discussion I went ahead and implemented it in 1232d19.

The implementation is simple, I'm a bit hesitant if this can have undesired side effects in the wild.

I think your analysis is correct, particularly the difference between going module path => filesystem path (what Python does) and the reverse (what we want to do).

I think the partial support is too confusing, so IMO we shouldn't do option 1 (I prefer 2 over 1).

I totally understand the concern with option 3. However, I think we can try it and see. We may end up with these long unintended module paths, but I don't think it would be actively dangerous (=> actually importing unintended stuff) because intermediate paths in namespace packages are not executing anything (there is no __init__.py to import).

Longer term, and this has already been brought by several people, I do think we need to add some concept of "workspace roots", which are Directory collector nodes directly below Session, and which put a strict bound on filesystem traversals (never going beyond them). (Also, initial conftests only collected from workspace roots. The confcutdir concept is gone. --pypkg args become workspace roots. All nodeids are rooted in roots, can't have <rootdir>/../bla.py or /foo/bar.py nodeids anymore). Hopefully I can put up a proper proposal sometime soon.

Suppose for some reason temp/ is in sys.path (possibly due to a misconfiguration), this means we could end up determining that core.py is be part of the package temp.some.folder.myproject.src.com.company.myapp.core, which is incorrect, depending on the order directories appear in sys.path, if temp/ appears first: temp/ or temp/some/folder/myproject/src.

Since we're iterating pkg_path.parents in order, I don't think there is ambiguity -- we'll always try com.company.myapp.core in temp/some/folder/myproject/src first, so that's the one that would be found, even if temp/ is in sys.path.

Regarding the initial implementation, in the loop for parent in pkg_path.parents:, is there some special handling needed if one of the parents has a __init__.py? Can namespace packages be nested in regular packages? Or the other way around?

Since we're iterating pkg_path.parents in order, I don't think there is ambiguity -- we'll always try com.company.myapp.core in temp/some/folder/myproject/src first, so that's the one that would be found, even if temp/ is in sys.path.

Yes, you are right.

Regarding the initial implementation, in the loop for parent in pkg_path.parents:, is there some special handling needed if one of the parents has a init.py?

Good catch, indeed if there is an __init__.py it is no longer a namespace package. Added a specific test for this.

Went ahead with option 3 then, please take a look.

I also double checked and the pytest-doctest-import-mismatch (the reproducer for the issue) still passes.

Good catch, indeed if there is an init.py it is no longer a namespace package. Added a specific test for this.

So I've just seen in the link you provided https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages a regular package nested inside of a namespace package... So I assume it is possible?

doc/en/explanation/pythonpath.rst

testing/test_pathlib.py

bluetech · 2024-02-25T17:45:49Z

src/_pytest/pathlib.py

+
+    Passing the full path to `models.py` will yield Path("src") and "app.core.models".
+
+    If consider_ns_packages is True, then we additionally check if the top-level directory


Good catch, indeed if there is an init.py it is no longer a namespace package. Added a specific test for this.

So I've just seen in the link you provided https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages a regular package nested inside of a namespace package... So I assume it is possible?

bluetech

Didn't review the code yet, just some light comments. Will review a bit later.

nicoddemus · 2024-02-25T19:32:05Z

So I've just seen in the link you provided https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages a regular package nested inside of a namespace package... So I assume it is possible?

(I can't seem to reply inline to your original comment)

Sub-packages can have __init__.py files, but not the directories that make up the top level of the namespace package.

Consider this:

dist1/
  com/
    company/
      app/
        core/
          __init__.py
        __init__.py
dist2/
  com/
    company/
      calc/
        algo/
          __init__.py
        __init__.py

In the example above, com.company is the namespace package (which is shared), while app.core and calc.algo are the sub-packages.

Using this simple script to test it:

import sys

sys.path.append(r"e:\Temp\src\dist1")
sys.path.append(r"e:\Temp\src\dist2")

import com.company.app.core.models
import com.company.calc.algo.algorithms
print(com.company.app.core.models)
print(com.company.calc.algo.algorithms)

This prints:

<module 'com.company.app.core.models' from 'e:\\Temp\\src\\dist1\\com\\company\\app\\core\\models.py'>
<module 'com.company.calc.algo.algorithms' from 'e:\\Temp\\src\\dist2\\com\\company\\calc\\algo\\algorithms.py'>

app.core and calc.algo are free to have __init__ files, but adding an __init__.py file to com/ or company/ will break the logic, and then com.company will no longer be considered a namespace package.

To prove this, we create dist1/com/__init__.py and run the script again:

λ py -3.12 foo.py
Traceback (most recent call last):
  File "e:\Temp\src\foo.py", line 10, in <module>
    import com.company.calc.algo.algorithms
ModuleNotFoundError: No module named 'com.company.calc'

But as I mentioned, the sub-packages can have __init__.py, but they are optional: removing all of them gets the same results as the first example. However this case (no __init__.py) is not supported under the current code.

This is why resolve_pkg_root_and_module_name will bail if it finds a __init__.py file while moving upwards in the herarchy.

bluetech

Went over the code now, it looks good to me in general! I left a few comments in addition to the previous ones.

Also for your consideration, I've split the PR into commits, I think it will help with reviewing/bisecting/reverting compared to one big commit. https://github.com/bluetech/pytest/commits/11475-importlib/

src/_pytest/pathlib.py

nicoddemus · 2024-03-02T15:41:05Z

src/_pytest/pathlib.py

    *,
    mode: Union[str, ImportMode] = ImportMode.prepend,
    root: Path,
+    consider_namespace_packages: bool,


Why not use a default here?

I prefer to force everywhere that calls it to pass the new option explicitly, lest we miss passing the option in production code by mistake.

bluetech

Looks good to me!

testing/test_pathlib.py

src/_pytest/pathlib.py

The test seems wrong, and we haven't been able to figure out what it's trying to test (the original issue is lost in time).

Ensure the implementation isn't changed to trigger such a bug.

Will be reused.

…name` This applies to `append` and `prepend` import modes; support for `importlib` mode will be added in a separate change.

…chanism As detailed in pytest-dev#11475 (comment), currently with `--import-mode=importlib` pytest will try to import every file by using a unique module name, regardless if that module could be imported using the normal import mechanism without touching `sys.path`. This has the consequence that non-test modules available in `sys.path` (via other mechanism, such as being installed into a virtualenv, PYTHONPATH, etc) would end up being imported as standalone modules, instead of imported with their expected module names. To illustrate: ``` .env/ lib/ site-packages/ anndata/ core.py ``` Given `anndata` is installed into the virtual environment, `python -c "import anndata.core"` works, but pytest with `importlib` mode would import that module as a standalone module named `".env.lib.site-packages.anndata.core"`, because importlib module was designed to import test files which are not reachable from `sys.path`, but now it is clear that normal modules should be imported using the standard mechanisms if possible. Now `imporlib` mode will first try to import the module normally, without changing `sys.path`, and if that fails it falls back to importing the module as a standalone module. This also makes `importlib` respect namespace packages. This supersedes pytest-dev#11931. Fix pytest-dev#11475 Close pytest-dev#11931

Fix pytest-dev#11475

Test with namespace packages support even when it will not find namespace packages to ensure it will at least not give weird results or crashes.

flying-sheep · 2024-03-04T09:20:13Z

/edit: moved to #11475 (comment)

nicoddemus changed the title ~~11475 importlib~~ Change importlib to first try to import modules using the standard mechanism Feb 17, 2024

nicoddemus force-pushed the 11475-importlib branch from 9dbb819 to e054ca6 Compare February 17, 2024 16:36

nicoddemus commented Feb 17, 2024

View reviewed changes

testing/test_pathlib.py Outdated Show resolved Hide resolved

nicoddemus force-pushed the 11475-importlib branch from b7bdb67 to bf112c3 Compare February 17, 2024 20:10

nicoddemus marked this pull request as ready for review February 17, 2024 20:13

nicoddemus commented Feb 17, 2024

View reviewed changes

src/_pytest/pathlib.py Show resolved Hide resolved

nicoddemus mentioned this pull request Feb 17, 2024

ModuleNotFoundError when using --doctest-modules, a src/ layout, and --import-mode=importlib (and no editable mode install) #11475

Closed

flying-sheep mentioned this pull request Feb 18, 2024

Use shortest module name for importlib imports #11931

Closed

nicoddemus force-pushed the 11475-importlib branch from bf112c3 to 6fdac9f Compare February 18, 2024 12:20

flying-sheep reviewed Feb 18, 2024

View reviewed changes

doc/en/explanation/pythonpath.rst Outdated Show resolved Hide resolved

bluetech requested changes Feb 18, 2024

View reviewed changes

nicoddemus commented Feb 18, 2024

View reviewed changes

testing/test_doctest.py Show resolved Hide resolved

nicoddemus commented Feb 18, 2024

View reviewed changes

src/_pytest/pathlib.py Outdated Show resolved Hide resolved

nicoddemus force-pushed the 11475-importlib branch from 8a0f1a9 to f953bf4 Compare February 18, 2024 20:27

nicoddemus requested a review from bluetech February 19, 2024 01:13

nicoddemus commented Feb 19, 2024

View reviewed changes

src/_pytest/pathlib.py Outdated Show resolved Hide resolved

bluetech reviewed Feb 19, 2024

View reviewed changes

nicoddemus mentioned this pull request Feb 23, 2024

8.0.2 and 8.1.0 release planning #12026

Closed

nicoddemus requested a review from bluetech February 25, 2024 14:34

nicoddemus force-pushed the 11475-importlib branch from 306d9e0 to 5cc0ee0 Compare February 25, 2024 14:35

bluetech reviewed Feb 25, 2024

View reviewed changes

bluetech reviewed Feb 27, 2024

View reviewed changes

src/_pytest/pathlib.py Outdated Show resolved Hide resolved

src/_pytest/pathlib.py Outdated Show resolved Hide resolved

src/_pytest/pathlib.py Outdated Show resolved Hide resolved

src/_pytest/pathlib.py Outdated Show resolved Hide resolved

bluetech force-pushed the 11475-importlib branch from 5cc0ee0 to 0ae96e5 Compare February 29, 2024 07:27

nicoddemus force-pushed the 11475-importlib branch from 0ae96e5 to 7dc2939 Compare March 2, 2024 15:39

nicoddemus commented Mar 2, 2024

View reviewed changes

nicoddemus requested a review from bluetech March 2, 2024 15:55

bluetech approved these changes Mar 2, 2024

View reviewed changes

testing/test_pathlib.py Outdated Show resolved Hide resolved

src/_pytest/pathlib.py Outdated Show resolved Hide resolved

nicoddemus added 13 commits March 2, 2024 16:13

testing/test_pathlib: remove test_issue131_on__init__

887e251

The test seems wrong, and we haven't been able to figure out what it's trying to test (the original issue is lost in time).

testing/test_doctest: make test_importmode more realistic

300ceb4

testing/test_pathlib: add an importlib test

dcf01fd

Ensure the implementation isn't changed to trigger such a bug.

pathlib: extract a function resolve_pkg_root_and_module_name

7524e60

Will be reused.

pathlib: extract a function _import_module_using_spec

4dea183

Will be reused.

pathlib: handle filenames starting with . in module_name_from_path

5867426

pathlib: consider namespace packages in `resolve_pkg_root_and_module_…

067daf9

…name` This applies to `append` and `prepend` import modes; support for `importlib` mode will be added in a separate change.

doc: update and improve import mode docs

5746b8e

pathlib: import signature and docs for import_path

199d4e2

Add consider_namespace_packages ini option

111c0d9

Fix pytest-dev#11475

testing/test_pathlib: parametrize namespace package option

aac720a

Test with namespace packages support even when it will not find namespace packages to ensure it will at least not give weird results or crashes.

doc: document consider_namespace_packages option

d6134bc

nicoddemus force-pushed the 11475-importlib branch from 7dc2939 to d6134bc Compare March 2, 2024 19:14

nicoddemus merged commit 89ee449 into pytest-dev:main Mar 3, 2024
24 checks passed

nicoddemus deleted the 11475-importlib branch March 4, 2024 11:02

pllim mentioned this pull request Mar 4, 2024

TypeError: import_path() missing 1 required keyword-only argument: 'consider_namespace_packages' (pytest 8.2.dev) scientific-python/pytest-doctestplus#240

Closed

jtbandes mentioned this pull request Mar 12, 2024

pytest 8.1 incompatibility: TypeError: import_path() missing 1 required keyword-only argument: 'consider_namespace_packages' ros2/launch#765

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Change importlib to first try to import modules using the standard mechanism #11997

Change importlib to first try to import modules using the standard mechanism #11997

nicoddemus commented Feb 17, 2024 •

edited

nicoddemus commented Feb 17, 2024

nicoddemus commented Feb 18, 2024

flying-sheep left a comment

nicoddemus commented Feb 18, 2024 •

edited

flying-sheep commented Feb 18, 2024

flying-sheep commented Feb 18, 2024

nicoddemus commented Feb 18, 2024

bluetech commented Feb 18, 2024

nicoddemus commented Feb 18, 2024

nicoddemus commented Feb 18, 2024

bluetech left a comment •

edited

nicoddemus commented Feb 18, 2024 •

edited

nicoddemus commented Feb 18, 2024 •

edited

nicoddemus commented Feb 18, 2024 •

edited

bluetech left a comment

bluetech Feb 19, 2024

nicoddemus Feb 19, 2024

nicoddemus Feb 19, 2024

nicoddemus Feb 24, 2024

nicoddemus Feb 24, 2024

bluetech Feb 24, 2024

nicoddemus Feb 25, 2024

bluetech Feb 25, 2024

bluetech Feb 25, 2024

bluetech left a comment

nicoddemus commented Feb 25, 2024 •

edited

bluetech left a comment

nicoddemus Mar 2, 2024

bluetech left a comment

flying-sheep commented Mar 4, 2024 •

edited


		Passing the full path to `models.py` will yield Path("src") and "app.core.models".

		If consider_ns_packages is True, then we additionally check if the top-level directory

Change importlib to first try to import modules using the standard mechanism #11997

Change importlib to first try to import modules using the standard mechanism #11997

Conversation

nicoddemus commented Feb 17, 2024 • edited

nicoddemus commented Feb 17, 2024

nicoddemus commented Feb 18, 2024

flying-sheep left a comment

Choose a reason for hiding this comment

nicoddemus commented Feb 18, 2024 • edited

flying-sheep commented Feb 18, 2024

flying-sheep commented Feb 18, 2024

nicoddemus commented Feb 18, 2024

bluetech commented Feb 18, 2024

nicoddemus commented Feb 18, 2024

nicoddemus commented Feb 18, 2024

bluetech left a comment • edited

Choose a reason for hiding this comment

nicoddemus commented Feb 18, 2024 • edited

nicoddemus commented Feb 18, 2024 • edited

nicoddemus commented Feb 18, 2024 • edited

bluetech left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bluetech left a comment

Choose a reason for hiding this comment

nicoddemus commented Feb 25, 2024 • edited

bluetech left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bluetech left a comment

Choose a reason for hiding this comment

flying-sheep commented Mar 4, 2024 • edited

nicoddemus commented Feb 17, 2024 •

edited

nicoddemus commented Feb 18, 2024 •

edited

bluetech left a comment •

edited

nicoddemus commented Feb 18, 2024 •

edited

nicoddemus commented Feb 18, 2024 •

edited

nicoddemus commented Feb 18, 2024 •

edited

nicoddemus commented Feb 25, 2024 •

edited

flying-sheep commented Mar 4, 2024 •

edited