CEP for the next evolution of Repodata (v2) and MatchSpec #111

wolfv · 2025-02-05T12:21:27Z

This defines new repodata with two additional fields and a modfied matchspec syntax:

extra (optional) dependency sets that can be activated by the user or other packages
conditional dependencies to be activated on a specific platform, or when other package versions are also pulled in (e.g. require six; if python <3.8)
flags to make it easier to select variants confidently (instead of globbing the build string)

Some initial discussion happened over the past days on:

TODO:

specify that we need to understand full-blown matchspecs in the repodata.v2 (e.g. with bracket syntax), because we want other packages to be able to request extras or flags).
Decide whether flag negation should be ~foo, !foo, or -foo.
Decide if we need to add a default flags entry to the repodata record, or another way to mark the default variant (can also still use down-priorization via track records)
Investigate ordering of flags and whether we should have some weighing e.g. for numerical flags (higher == better)? Or wether this should be decided by another order integer that the users can compute.

wolfv · 2025-02-05T12:31:10Z

Here are comments from the HackMD:

Should we consider a system like Spack has (https://spack.readthedocs.io/en/latest/basic_usage.html#specs-dependencies) or maybe Conan (https://docs.conan.io/2/reference/conanfile/attributes.html#options)?
Additionally, how would a package declare which flag is the default? (Edited)

For default flags I think we might want to deprecate the track_features field and instead add a priority: integer field that can hold any value. The user could mark the default this way. We could also use the inverse of priority, so that higher values are less desirable.

Or, maybe a better thought: we could also make it so that if priority: -1 we never enable this package, except if we request its flags directly.

Regarding Spack and Conan: I would be super hyped if you can distill this on how it could work for the conda ecosystem. I haven't had the time yet to read into it deeply. I am not a fan of super arbitrary code execution though.

mariusvniekerk · 2025-02-20T15:00:48Z

cep-repodata-next.md

+- `release`: only packages with `release` flag are used
+- `~release`: disallow packages with `release` flag
+- `?release`: if release flag available, filter on it, otherwise use any other
+- `gpu:*`: any flag starting with `gpu:` will be matched


can you add an example for the string matching for say blas:mkl

Would an exact match not work fine?

It would, we should just state how to do an exact match

You coudl just ask for flags = ["blas:mkl"] for an exact match :)

jaimergp · 2025-03-30T13:54:18Z

cep-repodata-next.md

+
+The proposed syntax is to extend the `MatchSpec` syntax by appending `; if <CONDITION>` after the current MatchSpec.
+
+We would like to also allow for AND and OR with the following syntax:


You probably need NOT and parentheses for precedence overrides, right?

In regular MatchSepc, we have , and | used for versions for and and or. I think we should keep thing similar, even if it means supporting and and or in versions.

If find this hard to distinguish when parsing the version. E.g.

python <3.8|>3.9 | numpy >=2.0 python <3.8|>3.9 or numpy >=2.0

I find the version with or easier to read than the one with pipes.

Environment markers have been doing fine with and and or, I don't think we need to introduce more character-based operators.

jaimergp · 2025-03-30T14:02:49Z

cep-repodata-next.md

+ - six; if python <3.8
+```
+
+The proposed syntax is to extend the `MatchSpec` syntax by appending `; if <CONDITION>` after the current MatchSpec.


It would be nice if we didn't need the ; because somehow conda will happily ignore the if parts while parsing MatchSpecs.

>>> from conda.models.match_spec import MatchSpec as M >>> M("python 3.8 * if python") MatchSpec("python==3.8[build=*]") >>> M("python 3.8 'if' if __win") # quote 'if' to force parse it as a build string MatchSpec("python==3.8='if'")

It will also ignore parenthesised blocks:

>>> M("python 3.8 * (__win)") MatchSpec("python==3.8[build=*]") >>> M("python 3.8 (__win)") MatchSpec("python==3.8") >>> M("python 3.8 (__win and __osx)") MatchSpec("python==3.8") >>> M("python 3.8 (if __win and __osx)") MatchSpec("python==3.8")

libmamba also ignores parentheses:

>>> from libmambapy.specs import MatchSpec as LibmambaMatchSpec >>>print(LibmambaMatchSpec.parse("python 3.8 * (__win and __osx)")) python==3.8 >>> print(LibmambaMatchSpec.parse("python 3.8 * (if __win and __osx)")) python==3.8

My suggestion would be to design the syntax like this:

name [version [build]] ('if' condition)

The if literal could be omitted, or replaced with with, if folks feel it's clearer that way. See discussion in #conda-maintainers > Conditional dependencies syntax in v2 environments & recipes @ 💬.

Another idea (not sure if a good one) could be: rather than make MatchSpecs more complex than they already are, build on the idea of selectors from the new recipe format and allow depends to contain objects like so:

depends: - python >=3.8 - if: python <3.8 then: six

In the recipe format, this is expressed via a variation on the selector to avoid being process at build time (if(run): for instance).

This disallow basically disallow conditionals outside of recipes (or format with selector), but makes a more consistent narrative around conditionals.

The idea was indeed also posted on zulip. One issue is that it then becomes harder for cli tools to adopt.

I propose we use the when syntax without a semicolon to force an error on older versions of conda that dont support it and the distinguish between the already established if syntax in recipe v1. We can use the same keyword in a more expanded form as the "build spec"

foobar when python >=3.8

E.g. in a recipe:

- if: unix then: foobar when: python >=3.8 # OR - when: python >=3.8 then: foobar # OR - "foobar when python >=3.8"

I like this when idea a lot, and combines well with the if/then syntax, but I'd like to discuss the serialized MatchSpec. foobar when python>=3.8 is unparsable because it could be understood as version=when, build=python>=3.8. Of course we could force parsing rules to "split on when first" and so on, but let me suggest something that wouldn't imply so many changes in the MatchSpec parsers: use a square bracket keyword.

foobar[when="python>=3.8"] foobar[when="__win"] foobar[when="python>=3.8 and __unix"]

AntoinePrv · 2025-04-15T08:49:35Z

cep-repodata-next.md

+
+## Conditional dependencies
+
+Conditional dependencies are activated when the condition is true. The most straight-forward conditions are `__unix`, `__win` and other platform specifiers. However, we would also like to support matchspecs in conditions such as `python >=3`.


I very much like this idea. An implementation note: while if __unix is reasonably easy to implement because it is "static", if python <3.8 is conceptually much harder as it is not something that can be decided ahead of solving. I requires to be able to adapt the dependencies of a package as partial candidates are investigated during solve.

Yep, this is a form of boolean dependencies in rpm (already supported by libsolv I believe)

This is the PR that implements this for resolvo: prefix-dev/resolvo#136

AntoinePrv · 2025-04-15T08:59:56Z

cep-repodata-next.md

+
+However, it would be nice if we could have a flexible, powerful and simple syntax to enable or disable "flags" on packages in order to select a variant.
+
+A RepodataRecord should get a new field "flags" that is a list of strings, such as:


How do flags and extra mix and overlap? Wouldn't conditional dependencies on a flag be enough to generate the extra category?

Flags are part of a variant. So there is no variation of flags for a single variant. E.g. flags could be used to say a particular variant is using cuda and another is used to target cpu. Extras are a way to select additional dependencies for a particular variant. If a variant also adds a CLI tool it provides the extra "cli". Only if that extra is requested by another package are particular dependencies also requested.

In technical terms extras can indeed be implemented as conditional dependencies. E.g. for a package my_package we could express it as typer when my_package[cli]. If there is a package that depends on my_package[cli] typer would also be required.

baszalmstra · 2025-05-13T11:31:49Z

cep-repodata-next.md

+
+The proposed syntax is to extend the `MatchSpec` syntax by appending `; if <CONDITION>` after the current MatchSpec.
+
+We would like to also allow for AND and OR with the following syntax:


If find this hard to distinguish when parsing the version. E.g.

python <3.8|>3.9 | numpy >=2.0 python <3.8|>3.9 or numpy >=2.0

I find the version with or easier to read than the one with pipes.

baszalmstra · 2025-05-13T11:35:52Z

cep-repodata-next.md

+ - six; if python <3.8
+```
+
+The proposed syntax is to extend the `MatchSpec` syntax by appending `; if <CONDITION>` after the current MatchSpec.


I propose we use the when syntax without a semicolon to force an error on older versions of conda that dont support it and the distinguish between the already established if syntax in recipe v1. We can use the same keyword in a more expanded form as the "build spec"

foobar when python >=3.8

E.g. in a recipe:

- if: unix then: foobar when: python >=3.8 # OR - when: python >=3.8 then: foobar # OR - "foobar when python >=3.8"

baszalmstra · 2025-05-13T11:42:48Z

cep-repodata-next.md

+
+However, it would be nice if we could have a flexible, powerful and simple syntax to enable or disable "flags" on packages in order to select a variant.
+
+A RepodataRecord should get a new field "flags" that is a list of strings, such as:


Flags are part of a variant. So there is no variation of flags for a single variant. E.g. flags could be used to say a particular variant is using cuda and another is used to target cpu. Extras are a way to select additional dependencies for a particular variant. If a variant also adds a CLI tool it provides the extra "cli". Only if that extra is requested by another package are particular dependencies also requested.

In technical terms extras can indeed be implemented as conditional dependencies. E.g. for a package my_package we could express it as typer when my_package[cli]. If there is a package that depends on my_package[cli] typer would also be required.

baszalmstra · 2025-05-13T11:43:36Z

cep-repodata-next.md

+
+## Conditional dependencies
+
+Conditional dependencies are activated when the condition is true. The most straight-forward conditions are `__unix`, `__win` and other platform specifiers. However, we would also like to support matchspecs in conditions such as `python >=3`.


This is the PR that implements this for resolvo: prefix-dev/resolvo#136

baszalmstra · 2025-05-13T11:45:18Z

cep-repodata-next.md

+    - pyxpgres >=8
+```
+
+When a user, or a dependency, selects an extra through a MatchSpec, the extra and it's dependencies are "activated". This is conceptually the same as having three packages with "exact" dependencies from the "extra" to the base package: `sqlalchemy`, `sqlalchemy-sqlite` and `sqlalchemy-postgres` – which is the workaround currently employed by a number of packages on conda-forge.


I think we should clarify what happens if an extra is requested for a package but the selected variant doesnt provide that extra. E.g. what happens if I depend on a foobar[extras=["doesntexist"]]

Maybe I missed it but its also not defined how to depend on an extra?

Yes, we discussed this today some more and there are a few options:

An extra implicitly always exists (as empty) and so we would always choose the latest "base" package (whether it has the extra or not). We would then warn if it does not have the extra. I believe this is the behavior that pip implements, and makes it easier to be forward compatible even if other dependencies might ask for an extra that does not exist anymore.

We could strictly require that the extra is there and otherwise fail (or select an older version of the package that has the extra).

We could forward propagate extras (e.g. the first time we see an extra, we implicitly add it to all later versions, even if empty) which would prevent the solver from choosing a version before the extra existed, but might choose a later one after the extra was removed).

I think we should decide on a behavior, most likely choosing the one from pip. We should also read up on the idea of adding a "default" extra (default dependencies that can be deselected with no-default-extra or something along the lines which I recently saw being proposed somewhere in PyPI world as part of wheel-next I think.

PEP for default extras: https://peps.python.org/pep-0771/

Do we have a proposal for the matchspec syntax for these extras? Something like this?

conda install sqlalchemy[sqlite]

What currently works is sqlalchemy[extras=sqlite].

Please note that [ ... ] is a syntax already in conda to specify key-value pairs, e.g. foobar[sha256="1234..."].

wolfv · 2025-07-18T13:52:59Z

cep-repodata-next.md

+
+## Flags for the repodata
+
+It's very natural to build different variants for a given package in the conda ecosystem with different properties: blas implementation, gpu / cuda version, and other variables make up the variant matrix for certain recipes.


Mental note that flags should be added to the variant hash to ensure that packages have unique names.

wolfv · 2025-07-18T14:00:43Z

This is what a recipe looks like - we have a branch where the tests are passing.

package:
  name: conditional
  version: 0.1.0

build:
  flags:
    - cuda
    - openmp:mpi

requirements:
  run:
    - rattler-build
    - bzip2 *; if rattler-build >=0.44
    - zstd *; if rattler-build <0.44

  extras:
    science:
      - numpy
      - matplotlib
    web:
      - flask
    cli:
      - click

tests:
  - script:
    - echo "Hello, world!"
    requirements:
      run:
        - rattler-build >=0.44

  - script:
    - echo "This is a test for Rattler < 0.44"
    requirements:
      run:
        - rattler-build <0.44

  - script:
    - echo "This is a test for Rattler < 0.44"
    requirements:
      run:
        - conditional [extras=[science, web]]

wolfv · 2025-07-22T15:13:11Z

Another comment to remind ourselves, to simplify the initial implementation:

we will not allow conditions in run_constraints (for now)
We will not allow extra groups to contain anything other than run dependencies (no run constraints or run exports)

baszalmstra · 2025-07-23T09:19:09Z

We just merged

feat!: add support for conditional dependencies prefix-dev/resolvo#136

which adds support for all features mentioned in this CEP. We are working on an preliminary version of this CEP in rattler based on this.

jezdez · 2025-07-30T17:29:21Z

Let's split this CEP up between the various proposals here, each have sufficiently complex to implement constraints.

baszalmstra · 2025-07-30T17:42:28Z

Let's split this CEP up between the various proposals here, each have sufficiently complex to implement constraints.

The reason we combined these is they are require changes to the repodata format. We aimed to bundle these together in a single change.

But I do understand the desire to split the different features. Do you have a suggestion how we can avoid having to bump the repodata version in each CEP?

jaimergp · 2025-07-31T08:44:21Z

I think nothing prevents us from saying something like "This CEP is co-submitted with X, Y, Z. All of them propose to bump to repodata version v2, the implementation of which MUST happen simultaneously when all CEPs have been reviewed and accepted or rejected".

wolfv · 2025-07-31T08:51:06Z

I think I would be pro-splitting if we would see lots of engagement on the topics presented here. But so far it is not an unwieldy discussion so I don't exactly see the point of splitting :)

jezdez · 2025-08-19T08:59:41Z

The point is that repodata and matchspec are two different technical specifications and shouldn't be bunched into one CEP since that makes referring and evolving them in the future much harder. Imagine reading a future CEP saying "This refers to the matchspec portion of CEP 45, but not the repodata part."

h-vetinari · 2025-08-19T22:57:16Z

"This CEP is co-submitted with X, Y, Z. All of them propose to bump to repodata version v2, the implementation of which MUST happen simultaneously when all CEPs have been reviewed and accepted or rejected".

One of that CEPs could be about this proposed design for a better run-export infrastructure, which will likely (probably? certainly?) require repodata changes. So v2 would be the moment to pull that off, because I'm not assuming we'll be doing this very often.

wolfv · 2025-09-04T16:07:46Z

When implementing support for conditional dependencies, we noted that using if foobar * and or bizbar might be confusing if and is used as a build string.

I think it might be sensible to change and and or to use && and || instead (C/C++ syntax) which are characters that are not allowed anywhere in a matchspec.

Thoughts? Looks less Pythonic for sure.

We could also allow and and or as "inputs" and change to && and || in the indexer.

Or we disallow build strings like exact match and/or and require the user to type foobar[build_string="and"] instead.

h-vetinari · 2025-09-05T04:04:19Z

if foobar * and or bizbar

I hate space-separated matchspecs with a burning passion, and this would make it 10 times worse. Let's aim to give people a grammar that they can resolve in their heads, without decrypting an ambiguous order of precedence, or having to look up the definition of the spec. IMO && and || are ubiquitous enough that they would be very good choices for this.

In the same vein, if we're doing MatchSpec v2, I would so like to get rid of semantically-relevant spaces everywhere, including between versions and build strings. We could just make foobar[build_string="..."] the default (or even required) representation.

danyeaw · 2025-10-28T16:47:38Z

I noticed that in CEP15 we already using the repodata v2 nominclature, and for implementations like for mamba, libsolv is already checking for repodata_version == 2. Should we refer to this change as v3 instead? Do we want to use repodata_version for this change as well or create a new repodata.v2.json like the current draft says?

jaimergp · 2025-10-31T10:24:21Z

if foobar * and or bizbar

I hate space-separated matchspecs with a burning passion, and this would make it 10 times worse. Let's aim to give people a grammar that they can resolve in their heads, without decrypting an ambiguous order of precedence, or having to look up the definition of the spec. IMO && and || are ubiquitous enough that they would be very good choices for this.

In the same vein, if we're doing MatchSpec v2, I would so like to get rid of semantically-relevant spaces everywhere, including between versions and build strings. We could just make foobar[build_string="..."] the default (or even required) representation.

Agreed, let's get rid of the ambiguity of space-separated fields. There's no need to keep it, and we have alternatives. We could require that conditions are only be expressed with bracket syntax.

jaimergp · 2025-11-05T11:11:24Z

As mentioned in #55, the feedback there is very valuable and should be referenced here when applicable (e.g. in the Rationale section that discusses why the proposed syntax was chosen).

dholth · 2025-11-12T14:54:36Z

cep-repodata-next.md

+
+## Backwards Compatibility
+
+The new `repodata.v2` will be served alongside the current format under `repodata.v2.json`. Older conda clients will continue using the v1 format. Packages using any of the new features will not be added to v1 of `repodata.json`.


Too bad about having six copies of repodata (.json, .json.zst, sharded, v2.*)

jaimergp

The new features proposed in this CEP are really exciting and I want to see this happen, so count with my support! Before I delve into the technical details, I'd like to mention a few editorial changes that would be required (and I'm happy to assist in fixing those). Right now, it feels that this is more of a "pre-CEP" writeup. Namely:

The template is not being followed. None of the proposed sections are used. It's particular important to have: Abstract, Rationale, Specification, Rejected Ideas, and References. The Copyright notice is mandatory.
There are a number of related PRs on-flight that can help with the definitions and context. For example, the repodata schema can be simply referred to as "the repodata schema as defined in CEP PR #135", and then marked as part of the "Requires" frontmatter metadata.
There are some missing or outdated references to implementation PRs (e.g. conda/rattler#1040 was closed in favor of conda/rattler#1550; conda/rattler#1816 is missing).
As mentioned elsewhere, this PR should be better split in three parts; one per new field. All of them can "require" each other so they are all part of the v3 repodata update.
I recommend resorting to MUST, SHOULD and MAY in the Specification section to clarify what's allowed and what's not.

Now onto the actual contents:

The repodata version 2 is taken. This needs to be version 3.
The conditionals syntax needs to be better specified. Right now it's unclear what happens with space-separated matchspecs, especially if they happen to have a build string and. I recommend constraining this so we don't end up with nested conditionals and other complications (unless intended!).
The strings allowed in "flags" are not well described. Maximum length, allowed characters and other specificities would be welcome.
The Backwards Compatibility section should cover what happens with the v1 repodata when a package carries dependencies with the new features. Would the two repodatas get out of sync? Are we expecting some packages to be only available in the new repodata? Are both repodata versions supposed to carry the same content? What's the expected behavior here?
- See this conda-whl-channel review for some tricks that may be useful here.
Can packages depend on other packages with their extras? If so, how is this specified? Recipe formats have only allowed name [version [build]] syntax so far. Is this the moment where we require repodata v3 to only use the canonical form pre-standardized in #82?

There's maybe some more nuance to this, but this is what I got after reading it again today! Thanks for listening 🤓 And I reiterate: I'm happy to help write this up in the format that we need!

baszalmstra · 2025-11-16T18:05:57Z

How do we deal with quotes in quotes if we want to express: foo[if="bar[build=\"*gpu\"]"]. Escape them like the above? Is that already something that is defined in other CEPs?

jaimergp · 2025-11-16T18:50:25Z

How do we deal with quotes in quotes if we want to express: foo[if="bar[build=\"*gpu\"]"]. Escape them like the above? Is that already something that is defined in other CEPs?

I think we support both single and double quotes, so they can be mixed, but also escaped. That should be part of #82.

repodata-next

3a88a3e

wolfv mentioned this pull request Feb 5, 2025

feat: implement flags conda/rattler#1040

Closed

wolfv mentioned this pull request Feb 8, 2025

Optional groups of dependencies conda/conda#7502

Open

1 task

mariusvniekerk reviewed Feb 20, 2025

View reviewed changes

traversaro mentioned this pull request Mar 26, 2025

DEV: pin CUDA variant for PyTorch data-apis/array-api-extra#186

Merged

jaimergp reviewed Mar 30, 2025

View reviewed changes

weiji14 mentioned this pull request Apr 1, 2025

Zarr v3 Support and conda-forge versus pypi dependencies nsidc/earthaccess#974

Open

AntoinePrv reviewed Apr 15, 2025

View reviewed changes

weiji14 mentioned this pull request Apr 16, 2025

Packaging the optional s3 dependencies? conda-forge/rasterio-feedstock#329

Open

1 task

weiji14 mentioned this pull request Apr 27, 2025

Add NVIDIA TransformerEngine conda-forge/staged-recipes#29403

Merged

10 tasks

baszalmstra reviewed May 13, 2025

View reviewed changes

pavelzw mentioned this pull request May 21, 2025

pixi search should take down_prioritize_variant into account prefix-dev/pixi#3780

Open

h-vetinari mentioned this pull request May 22, 2025

ABI compatibility for modern Fortran packages conda-forge/flang-activation-feedstock#14

Open

wolfv commented Jul 18, 2025

View reviewed changes

wolfv mentioned this pull request Jul 23, 2025

feat: parse matchspec conditions and translate to resolvo conda/rattler#1545

Merged

lucascolley mentioned this pull request Jul 27, 2025

Install bracketed dependencies? prefix-dev/pixi#4210

Closed

2 tasks

weiji14 mentioned this pull request Jul 27, 2025

split xarray into multi-output conda-forge/xarray-feedstock#112

Open

lucascolley mentioned this pull request Aug 11, 2025

optype v0.13.1 conda-forge/optype-feedstock#25

Closed

3 tasks

lucascolley mentioned this pull request Sep 15, 2025

feat(install): allow conda package subset selection (e.g. pixi i --skip) via manifest prefix-dev/pixi#4569

Open

Hofer-Julian mentioned this pull request Oct 16, 2025

Finalize the proposal for extras with optional dependencies (dev-dependencies) prefix-dev/pixi#4764

Open

jezdez mentioned this pull request Oct 27, 2025

Optional Dependencies for conda v2 #55

Draft

This was referenced Oct 28, 2025

Support for repodata and MatchSpec for conditional / extra / flags mamba-org/mamba#4089

Open

Update repodata and MatchSpec support for conditionals / flags / extras based on latest CEP draft conda/rattler#1790

Open

This was referenced Nov 4, 2025

Discovery: Repodata v3 Backwards Compatibility for Wheels conda/conda#15380

Closed

Prototype conda-rattler-solver for repodata v3 support conda-incubator/conda-pypi#160

Closed

dholth reviewed Nov 12, 2025

View reviewed changes

jaimergp requested changes Nov 16, 2025

View reviewed changes

lucascolley mentioned this pull request Dec 2, 2025

BLD/DEV/CI: ASAN at your fingertips! scipy/scipy#24066

Draft


		The proposed syntax is to extend the `MatchSpec` syntax by appending `; if <CONDITION>` after the current MatchSpec.

		We would like to also allow for AND and OR with the following syntax:


		## Conditional dependencies

		Conditional dependencies are activated when the condition is true. The most straight-forward conditions are `__unix`, `__win` and other platform specifiers. However, we would also like to support matchspecs in conditions such as `python >=3`.


		However, it would be nice if we could have a flexible, powerful and simple syntax to enable or disable "flags" on packages in order to select a variant.

		A RepodataRecord should get a new field "flags" that is a list of strings, such as:


		## Flags for the repodata

		It's very natural to build different variants for a given package in the conda ecosystem with different properties: blas implementation, gpu / cuda version, and other variables make up the variant matrix for certain recipes.


		## Backwards Compatibility

		The new `repodata.v2` will be served alongside the current format under `repodata.v2.json`. Older conda clients will continue using the v1 format. Packages using any of the new features will not be added to v1 of `repodata.json`. No newline at end of file

CEP for the next evolution of Repodata (v2) and MatchSpec #111

Are you sure you want to change the base?

CEP for the next evolution of Repodata (v2) and MatchSpec #111

Uh oh!

Conversation

wolfv commented Feb 5, 2025 • edited by jaimergp Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wolfv commented Feb 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaimergp Mar 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaimergp Mar 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wolfv commented Feb 5, 2025 •

edited by jaimergp

Loading

jaimergp Mar 30, 2025 •

edited

Loading

jaimergp Mar 30, 2025 •

edited

Loading

jezdez commented Jul 30, 2025 •

edited

Loading

jezdez commented Aug 19, 2025 •

edited

Loading

h-vetinari commented Sep 5, 2025 •

edited

Loading

jaimergp commented Nov 5, 2025 •

edited

Loading