Load `default_env.nu`/`default_config.nu` before user `env.nu`/`config.nu` by NotTheDr01ds · Pull Request #14249 · nushell/nushell

NotTheDr01ds · 2024-11-04T16:40:33Z

Release-Notes Short Description

Nushell now always loads its internal default_env.nu before the user env.nu is loaded, then loads the internal default_config.nu before the user's config.nu is loaded. This allows for a simpler user-configuration experience. Details are in this blog entry along with an updated Configuration Chapter

Description

Implements the main ideas in #13671 and a few more:

Users can now specify only the environment and config options they want to override in their env.nu and config.nuand yet still have access to all of the defaults:
- default_env.nu (internally defined) will be loaded whenever (and before) the user's env.nu is loaded.
- default_config.nu (internally defined) will be loaded whenever (and before) the user's config.nu is loaded.
No more 900+ line config out-of-the-box.
Faster startup (again): ~40-45% improvement in launch time with a default configuration.
New keys that are added to the defaults in the future will automatically be available to all users after updating Nushell. No need to regenerate config to get the new defaults.
It is now possible to have different internal defaults (which will be used with -c and scripts) vs. REPL defaults. This would have solved many of the user complaints about the display_errors implementation.
A basic "scaffold" config.nu and env.nu are created on first launch (if the config directory isn't present).
Improved "out-of-the-box" experience (OOBE) - No longer asks to create the files; the minimal scaffolding will be automatically created. If deleted, they will not be regenerated. This provides a better "out-of-the-box" experience for the user as they no longer have to make this decision (without much info on the pros or cons) when first launching.
~~(New: 2024-11-07) Runs the env_conversions process after the default_env.nu is loaded so that users can treat Path/PATH as lists in their own config.~~
(New: 2024-11-08) Given the changes in Refactor config updates #13802, default_config.nu will be a minimal file to minimize load-times. This shaves another (on my system) ~3ms off the base launch time.
- Related: Keybindings, menus, and hooks that are already internal defaults are no longer duplicated in $env.config. The documentation will be updated to cover these scenarios.
(New: 2024-11-08) Move existing "full" default_config.nu to sample_config.nu for short-term "documentation" purposes.
(New: 2024-11-18) Move the dark-theme and light-theme to Standard Library and demonstrate their use - Also improves startup times, but we're reaching the limit of optimization.
(New: 2024-11-18) Extensively documented/commented sample_env.nu and sample_config.nu. These can be displayed in-shell using (for example) config nu --sample | nu-highlight | less -R. Note: Much of this will eventually be moved to or (some) duplicated in the Doc. But for now, this some nice in-shell doc that replaces the older "commented/documented default".
(New: 2024-11-20) Runs the ENV_CONVERSIONS process (1) after the default_env.nu (allows PATH to be used as a list in user's env.nu) and (2) before default_config.nu is loaded (allows user's ENV_CONVERSIONS from their env.nu to be used in their config.nu).
(New: 2024-11-20) The default ENV_CONVERSIONS is now an empty record. The internal Rust code handles PATH (and variants) conversions regardless of the ENV_CONVERSIONS variable. This shaves a very small amount of time off the startup. Reset - Looks like there might be a bug in nu-enginer::env::ensure_path() on Windows that would need to be fixed in order for this to work.

User-Facing Changes

By default, you shouldn't see much, if any, change when running this with your existing configuration.

To see the greatest benefit from these changes, you'll probably want to start with a "fresh" config. This can be easily tested using something like:

let temp_home = (mktemp -d)
$env.XDG_CONFIG_HOME = $temp_home
$env.XDG_DATA_HOME = $temp_home
./target/release/nu

You should see a message where the (mostly empty) env.nu and config.nu are created on first start. Defaults should be the same (or similar to) those before the PR. Please let me know if you notice any differences.

Users should now specify configuration in terms of overrides of each setting. For instance, rather than modifying history settings in the monolithic config.nu, the following is recommended in an updated config.nu:

$env.config.history = {
  file_format: sqlite,
  sync_on_enter: true
  isolation: true
  max_size: 1_000_000
}

or even just:

$env.config.history.file_format = sqlite
$env.config.history.isolation: true
$env.config.history.max_size = 1_000_000

Note: It seems many users are already appending a source my_config.nu (or similar pattern) to the end of the existing config.nu to make updates easier. In this case, they will likely want to remove all of the previous defaults and just move their my_config.nu to config.nu.

Note: It should be unlikely that there are any breaking changes here, but there's a slim chance that some code, somewhere, expects an absence of certain config values. Otherwise, all config values are available before and after this change.

Tests + Formatting

🟢 toolkit fmt
🟢 toolkit clippy
🟢 toolkit test
🟢 toolkit test stdlib

After Submitting

Configuration Chapter (and related) of the doc is currently WIP and will be finished in time for 0.101 release.

NotTheDr01ds · 2024-11-04T16:43:43Z

@fdncred For your gist on this topic, I believe we'll find that default_config.nu and default_env.nu are loaded in every case where your gist shows config.nu and env.nu as loading. With, of course, the exception of --no-defaults.

For example, if --no-config-file or -c are specified, then none of the config files loaded, including default_env.nu, env.nu, default_config.nu, and config.nu.

NotTheDr01ds · 2024-11-04T17:16:51Z

Edit: This was implement:

I'm thinking (but not totally sure yet) that we might could also move the "path conversion" code so that it runs after the default_env.nu. If we could, this would allow the $env.PATH to be treated as a Nushell list inside env.nu.

src/config_files.rs

src/command.rs

IanManske · 2024-11-05T05:16:41Z

Thanks for the PR! Just tried this out, but it look likes $env.config is undefined on startup.

NotTheDr01ds · 2024-11-05T10:17:41Z

@IanManske Thanks for testing! Can you give me some more detail on your startup?

I'm assuming you are using a fresh install or XDG_CONFIG_HOME since otherwise your $env.config should still be getting (at least) populated from the existing config, right?
If there's no initial config/env, what is getting generated when you startup with this PR?
Does view files | find config and view files | find env show the defaults loading?
Platform?
Anything else you can tell me to help me reproduce?

Thanks!

IanManske · 2024-11-06T02:51:08Z

Sure thing, I'm on 938cd2c and ran:

cargo b
./target/debug/nu -n
$env.config

NotTheDr01ds · 2024-11-06T13:28:45Z

@IanManske Ah - Thanks! That's working as expected then. When you run with -n we don't load any config/env files, and that includes the defaults. You can confirm this with the view files command I mentioned above.

If you want to test in a clean environment:

$env.XDG_CONFIG_HOME = (mktemp -d)
./target/debug/nu

You should see something like:

Environment config file created at: /tmp/tmp.n4eZIEkAuG/nushell/env.nu
Config file created at: /tmp/tmp.n4eZIEkAuG/nushell/config.nu

... followed by the banner. And $env.confg should be fully populated there.

After exiting that shell, you can clean up with:

rm -r $env.XDG_CONFIG_HOME
hide-env XDG_CONFIG_HOME

fdncred · 2024-11-06T22:36:26Z

@fdncred For your gist on this topic, I believe we'll find that default_config.nu and default_env.nu are loaded in every case where your gist shows config.nu and env.nu as loading.

@NotTheDr01ds it would be good if someone would take my gist and turn it into some documentation with these changes you're talking about.

NotTheDr01ds · 2024-11-06T22:58:52Z

@fdncred Sure thing - I'll get that in when I do that Config chapter update/rewrite for these changes.

NotTheDr01ds · 2024-11-06T23:45:40Z

In today's meeting, we discussed several options that might allow users to disable the loading of defaults:

The flag in place at the moment. Disadvantage is that (a) it's another flag, and (b) it would have to be added every time.
A "magic" file named something like .no-defaults that, if present in the config directory, would prevent defaults from loading. This was seen as an improvement over the flag, but general consensus was that it is a bit "hokey" (my wording).
Instead of auto-loading, move the defaults to a config subcommand that the user would call in their own env.nu/config.nu. This might work, but I'm not sure we could still allow the environment conversions to work in that case. I'd have to play with it to see. This would also be a solution where the (we believe) minority of users would "do nothing" to not load the defaults, but the (we believe) vast majority would have to add a command to both env.nu and config.nu.
Ultimately we decided that it's probably best to see if this is really going to be a problem before we decide on or implement a solution. If most users just load the defaults and then shift to an "override" config, then we might not need a solution at all.

So I'm going to back out the flag.

We also decided we will hold this until after 0.100.0 is released. This will give us more time for it to bake in nightly's/etc.

NotTheDr01ds · 2024-11-07T00:45:11Z

Also, as requested during today's meeting, here's a link to the gist.

stormasm · 2024-11-07T01:58:50Z

@NotTheDr01ds Thank you kindly for adding a summary of what we discussed in the meeting today 😄

NotTheDr01ds · 2024-11-07T16:48:44Z

One thing that I honestly didn't notice until after the call yesterday is just how substantially @IanManske's #13802 changed the way config works. I usually just gloss over PR's with "refactor" in the title ;-).

That's a great change, and does a lot of what this PR would have done if #13802 wasn't in place.

But the combination of both of these gives us even more opportunities, I think.

I'm thinking of now changing default_config.nu to (for starters) be:

$env.config = {}

Because of Ian's work, this will now populate all values from impl Default for Config into the record.

And ... Sweet! This shaves another (average) ~3ms (on my system) off a default/base launch time compared to 0.99.1.

There might be a few values we want or need to populate back in, so that the "internal defaults" and default_config.nu values totally sync up, but for the most part the Rust-internal-defaults will give us (another) decent startup-performance boost.

IanManske · 2024-11-08T04:43:18Z

Some of the config settings will probably be hard to set through the Rust code like the hooks and theme, so I agree we probably still want something (or most things?) in the default_config.nu. Plus this would be accessible through config nu --default as a temporary form of documentation.

fdncred · 2024-11-08T09:57:37Z

Related / maybe Unrelated

Just posting what I posted on Discord
taking a cue from ghostty, it may be nice to have a functionality that does this :

ghostty +show-config <-- shows the current configuration settings in a valid ghostty config format. 278 lines
ghostty +show-config --default <-- shows every single option with its default (without a config file) value 442 lines
ghostty +show-config --default --docs <-- shows every single option with its default (without a config file) value + documentation that explains every options use case. 1,960 lines
ghostty +show-config --changes-only <-- only show the options that have been changed from the default, no effect if --default is specified

NotTheDr01ds · 2024-11-08T11:47:26Z

Plus this would be accessible through config nu --default as a temporary form of documentation.

At least temporarily, I'm planning on moving the current (fully-loaded) version of default_config.nu to sample_config.nu and having it be accessible through the config command for this purpose. Whether as config nu --default or config nu --sample or whatever. I'm not sure that's the best "documentation", but it will service temporarily.

Long-term, I'd like to implement something like @fdncred pointed out with the Ghostty stuff at some point. In our case, though, it would be something like:

# Flattened tables
help config-option --list/-l --current
help config-option --list-l --default
help config-option --list-l --overrides

# Perhaps, to avoid too deeply nested a structure above:
help keybindings ...
help hooks ...

# Show help on option
help config-option <option>

I wonder if we could add the documentation on each setting directly to the configuration as we do with commands?

fdncred · 2024-11-09T13:16:27Z

I kind of feel like there needs to be a readme.md in the default_files folder that describes the config files. we have 3 config files, config, env, login. some of those have default_ files, some have scaffold_ files, some have sample_ files but it's not the same for all 3 groups so it's a bit confusing.

default_

has config and env but no login

scaffold_

has config and env but no login

sample_

has config and login but no env

even after reading the code i'm confused about all these files, what their purpose is, and when they're loaded. LOL.

NotTheDr01ds · 2024-11-09T22:10:15Z

@fdncred Fair enough - It's (a) confusing, and (b) probably in flux regardless. I'll add a README there, but long-term, I think both the sample_ files go away.

I'm not even sure what the purpose of sample_login.nu is - It's not used anywhere in the code, so I'm going to move the info there to the Configuration chapter of the Book and then remove it.

fdncred · 2024-11-09T22:15:00Z

sample_login.nu was there to (1) let people know that there could be a login.nu file and (2) what the syntax needed to look like and for documentation purposes.

NotTheDr01ds · 2024-11-09T23:42:17Z

Right, but it wasn't actually used - I would have thought it would be written to the config directory, but it's not. I don't think most users were going to find it at crates/nu-utils/src/sample_files/sample_login.nu ;-)

fdncred · 2024-11-11T15:02:03Z

I'm trying to test this out on Windows my setting the XDG_CONFIG_HOME var but I'm having problems.

If I have this I get an error.

$env.config.table = {
  show_empty: false
  trim: {
    truncating_suffix: "…"
  }
  header_on_separator: true
  footer_inheritance: true
}

Error: nu::shell::invalid_config

  × Encountered 1 error(s) when updating config

Error: nu::shell::missing_required_column

  × $env.config.table.trim requires a 'methodology' column
    ╭─[C:\Users\fdncred\.config\nushell\config.nu:96:9]
 95 │       show_empty: false
 96 │ ╭─▶   trim: {
 97 │ │       truncating_suffix: "…"
 98 │ ├─▶   }
    · ╰──── has no 'methodology' column
 99 │       header_on_separator: true
    ╰────

If I replace it with my entire $env.config.table section it gets passed it and seems to work. I'm wondering if:
A. I've done something wrong with my config.
B. There are some dependencies in some of the config sections where particular sections are required like methodology.

Here's my config & env in case someone can spot something wrong.
env.nu.txt
config.nu.txt

rgwood · 2024-11-23T18:16:44Z

This looks like a big improvement+simplification. Thank you!

# Description As a bit of a follow-on to #13802 and #14249, this (pretty much a "one-line" change) really does *always* populate the `$env.config` record with the `nu-protocol::config` defaults during startup. This means that an `$env.config` record is value (with defaults) even during: * `nu -n` to suppress loading of config files * `nu -c <commandstring>` * `nu <script>` # User-Facing Changes There should be no case in which there isn't a valid `$env.config`. * Before: ```nushell nu -c "$env.config" # -> Error ``` * After: ```nushell nu -c "$env.config" # -> Default $env.config record ``` Startup time impact is negligible (17.072µs from `perf!` on my system) - Seems well worth it. # Tests + Formatting Added tests for several `-n -c` cases. - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting Config chapter update still in progress.

# Description Due to #14249 loading `default_env.nu` before the user's `env.nu`, variables that were defined there were overriding: * Inherited values * Some values that were set in the Rust code, such as the `NU_LIB_PATH` when set using `--include-path`. This change checks to see if a variable already exists, uses its value if so, and sets the default value otherwise. Note: `ENV_CONVERSIONS` is still "forced" to a default value regardless, as it needs to run reliably. There's probably not much reason to inherit it, but I'm open to the idea if there's a use-case. # User-Facing Changes * Before: Variables that were set in `default_env.nu` always overrode those that were inherited from the parent process or set internally * After: Inherited and internal environment variables will take priority. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting Will try to find a good place to mention this behavior in the Config chapter updates

# Description #14249 loaded `convert_env_values()` several times to force more updates to `ENV_CONVERSION`. This allows the user to treat variables as structured data inside `config.nu` (and others). Unfortunately, `convert_env_values()` did not originally anticipate being called more than once, so it would attempt to re-convert values that had already been converted. This usually leads to an error in the conversion closure. With this PR, values are only converted with `from_string` if they are still strings; otherwise they are skipped and their existing value is used. # User-Facing Changes No user-facing change when compared to 0.100, since closures written for 0.100's `ENV_CONVERSION` now work again without errors. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` - # After Submitting Will remove the "workaround" from the Config doc preview.

PerchunPak · 2024-12-16T11:29:47Z

crates/nu-utils/src/default_files/sample_config.nu

@@ -0,0 +1,792 @@
+# Nushell Config File
+#
+# version = "0.99.2"


wrong version?

@PerchunPak Good catch. @NotTheDr01ds I'm also thinking all these config/env/scaffold/sample files should have a version at the top. Also, I'm getting an error in one. It should be = not :.

there are many syntax errors in the nightly build, not only this one

nushell/crates/nu-utils/src/default_files/sample_config.nu

Line 483 in 39770d4

plugins: {}

nushell/crates/nu-utils/src/default_files/sample_config.nu

Line 89 in 39770d4

edit_mode: "emacs"

and many more

i will probably create a pr fixing all those

…nt prompt vars (#14579) # Description With `NU_LIB_DIRS`, `NU_PLUGIN_DIRS`, and `ENV_CONVERSIONS` now moved out of `default_env.nu`, we're down to just a few left. This moves all non-closure `PROMPT` variables out as well (and into Rust `main()`. It also: * Implements #14565 and sets the default `TRANSIENT_PROMPT_COMMAND_RIGHT` and `TRANSIENT_MULTILINE_INDICATOR` to an empty string so that they are removed for easier copying from the terminal. * Reverses portions of #14249 where I was overzealous in some of the variables that were imported * Fixes #12096 * Will be the final fix in place, I believe, to close #13670 # User-Facing Changes Transient prompt will now remove the right-prompt and multiline-indicator once a commandline has been entered. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` - # After Submitting Release notes addition

NotTheDr01ds · 2024-12-16T19:04:58Z

@PerchunPak Yes, the conversion from the old default_config.nu with a monolithic record to the new "sample" with individual key-value settings was a pretty manual, so I missed a few that needed to be changed like this. Thanks for catching these!

As for the version numbers, I assumed these were added automatically during the build process, but I didn't dive in to be sure. I'm fairly certain no one goes in and manually updates them each release ;-)

@fdncred I'm not sure the sample_config.nu should have a version - We've tried to make sure that doc isn't versioned in most cases, right?

NotTheDr01ds · 2024-12-16T19:29:34Z

Actually, looking through these, none of them should be "versioned" any longer. That's a relic of having breaking changes in default configs, which #14249 does away with.

fdncred · 2024-12-17T00:38:44Z

@NotTheDr01ds I think we should version all of them to demonstrate which version they're released with and compatible with. For instance, if you rename something like $env.config.<any_key_mentioned> there could be mistakes that lead to confusion for people.

@NotTheDr01ds

For some reason, it had multiple syntax errors and other issues, like undefined options. Would be great to add a test for sourcing all example configs, but I don't know rust See also #14249 (comment)  CC @NotTheDr01ds

# Description Takes advantage of #14591 to remove the now-necessary calls to `convert_env_values()` that I added in #14249. The function is now just called once to convert `PATH`. Also removed the Windows-build-time checks for `ensure_path`, since previous case-insensitivity fixes make this unnecessary as well. # User-Facing Changes None - #14591 now handles conversion 'on-demand'. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting N/A

In #14249, `config reset` wasn't updated to use the scaffold config files, so running `config reset` would accidentally reset the user's config to the internal defaults. This PR updates it to use the scaffold files.

NotTheDr01ds changed the title ~~Always load default config contents~~ Always load default env/config values Nov 4, 2024

sholderbach added the A:configuration Issue related to nu's configuration label Nov 4, 2024

fdncred reviewed Nov 4, 2024

View reviewed changes

src/config_files.rs Outdated Show resolved Hide resolved

fdncred reviewed Nov 4, 2024

View reviewed changes

src/command.rs Outdated Show resolved Hide resolved

NotTheDr01ds added the status:wait-until-after-nushell-release label Nov 6, 2024

NotTheDr01ds marked this pull request as draft November 7, 2024 01:09

NotTheDr01ds force-pushed the always-load-defaults branch from 8f0b3c3 to 9aa2d04 Compare November 8, 2024 02:59

This was referenced Nov 8, 2024

refactor the default and the valid color_config #8703

Open

Rust-internal color_config value does not match default_config.nu #14285

Open

NotTheDr01ds force-pushed the always-load-defaults branch from ac69246 to 2a5ce7d Compare November 9, 2024 22:07

NotTheDr01ds added 3 commits November 20, 2024 10:16

Re-add ENV_CONVERSIONS to fix Windows issue

b9f6000

Attempt fix for Windows virtual_env test

2b21da6

Fix small typo

1f10ac7

fdncred merged commit 4ed25b6 into nushell:main Nov 20, 2024

github-actions bot added this to the v0.101.0 milestone Nov 20, 2024

NotTheDr01ds changed the title ~~Always load default env/config values~~ Load default_env.nu/default_config.nu before user env.nu/config.nu Nov 24, 2024

This was referenced Nov 24, 2024

No longer load default_env.nu by default when running with -c or <script.nu> #14428

Closed

Always populate config record during startup #14435

Merged

add the alt+enter keybinding for insert_newline into default config #13606

Closed

NotTheDr01ds mentioned this pull request Nov 28, 2024

Allow inherited environment variables #14467

Merged

This was referenced Dec 4, 2024

Only run from_string conversion on strings #14509

Merged

Unnecessary global variables from config #10183

Closed

JoaquinTrinanes mentioned this pull request Dec 8, 2024

nushell: Structured settings nix-community/home-manager#6184

Merged

5 tasks

NotTheDr01ds mentioned this pull request Dec 13, 2024

Moves additional env vars out of default_env and updates some transient prompt vars #14579

Merged

PerchunPak reviewed Dec 16, 2024

View reviewed changes

PerchunPak mentioned this pull request Dec 16, 2024

Fix issues in the example configs #14601

Merged

NotTheDr01ds mentioned this pull request Dec 27, 2024

Remove no-longer-needed convert_env_values calls #14681

Merged

NotTheDr01ds mentioned this pull request Jan 5, 2025

Update config reset to use scaffold files #14759

Closed

NotTheDr01ds mentioned this pull request Aug 17, 2025

Simplify user configuration #13671

Closed

Conversation

NotTheDr01ds commented Nov 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Release-Notes Short Description

Description

User-Facing Changes

Tests + Formatting

After Submitting

Uh oh!

NotTheDr01ds commented Nov 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NotTheDr01ds commented Nov 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

IanManske commented Nov 5, 2024

Uh oh!

NotTheDr01ds commented Nov 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

IanManske commented Nov 6, 2024

Uh oh!

NotTheDr01ds commented Nov 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fdncred commented Nov 6, 2024

Uh oh!

NotTheDr01ds commented Nov 6, 2024

Uh oh!

NotTheDr01ds commented Nov 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NotTheDr01ds commented Nov 7, 2024

Uh oh!

stormasm commented Nov 7, 2024

Uh oh!

NotTheDr01ds commented Nov 7, 2024

Uh oh!

IanManske commented Nov 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fdncred commented Nov 8, 2024

Uh oh!

NotTheDr01ds commented Nov 8, 2024

Uh oh!

fdncred commented Nov 9, 2024

default_

scaffold_

sample_

Uh oh!

NotTheDr01ds commented Nov 9, 2024

Uh oh!

fdncred commented Nov 9, 2024

Uh oh!

NotTheDr01ds commented Nov 9, 2024

Uh oh!

fdncred commented Nov 11, 2024

Uh oh!

rgwood commented Nov 23, 2024

Uh oh!

PerchunPak Dec 16, 2024

Choose a reason for hiding this comment

Uh oh!

fdncred Dec 16, 2024 • 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!

PerchunPak Dec 16, 2024

Choose a reason for hiding this comment

Uh oh!

NotTheDr01ds commented Dec 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NotTheDr01ds commented Dec 16, 2024

Uh oh!

fdncred commented Dec 17, 2024

Uh oh!

Reviewers

NotTheDr01ds commented Nov 4, 2024 •

edited

Loading

NotTheDr01ds commented Nov 4, 2024 •

edited

Loading

NotTheDr01ds commented Nov 4, 2024 •

edited

Loading

NotTheDr01ds commented Nov 5, 2024 •

edited

Loading

NotTheDr01ds commented Nov 6, 2024 •

edited

Loading

NotTheDr01ds commented Nov 6, 2024 •

edited

Loading

IanManske commented Nov 8, 2024 •

edited

Loading

fdncred Dec 16, 2024 •

edited

Loading

NotTheDr01ds commented Dec 16, 2024 •

edited

Loading