NixOS module support: Separate NUR nixpkgs from repos nixpkgs, avoid callPackages #27

infinisil · 2018-07-09T22:09:23Z

This is essential to get modules in NUR to work. By taking a separate
argument for NUR's nixpkgs (for fetchgit, fetchzip and lib), we don't
need to evaluate the nixpkgs used for repos.

This also implies that you won't be able to callPackage NUR anymore,
and instead you'll have to use import (builtins.fetchGit ".../NUR") { inherit pkgs; } instead. Doing this also prevents the evaluation of
pkgs. In case of NixOS, this pkgs depends on your whole config, which is
the source of the recursion. Evaluating this at the last possible moment
is key.

This also means that you won't be able to take package arguments in a
repo definition, you instead get just pkgs, also to avoid evaluation
of it.

New install instructions would be

{
  packageOverrides = pkgs: {
    nur = import (builtins.fetchGit "https://github.com/nix-community/NUR") {
      inherit pkgs;
    };
  };
}

To get NixOS modules to work you'll have to use something like

{ pkgs, ... }:
let
  nur = import (builtins.fetchGit "https://github.com/nix-community/NUR") {
    inherit pkgs;
  };
in {
  imports = [
    nur.repos.infinisil.module
  ];
}

Preferably one would set nur=https://github.com/nix-community/NUR in their NIX_PATH, which allows one to do

{ pkgs, ... }: {
  imports = [
    (import <nur> { inherit pkgs; }).repos.infinisil.module
  ];
}

Also the pkgs argument should be made optional, so you don't even need to pass it when importing a module.

Docs and stuff would need to be updated, I might do this later.

Mic92 · 2018-07-11T00:53:26Z

I like the idea of having a separate expression source for fetchgit and co. I try to think about the most straightforward syntax the next days or so. Documentation should be definitely added before merging any changes.

Mic92 · 2018-07-11T00:59:07Z

One thing that sucks about fetchgit or fetchTarball is that it will not fallback to a cached version when the ttl expires. I could not change my timezone without internet that way with nur modules in my list. Maybe a channel like behavior is more appropriate.

dtzWill · 2018-07-11T02:20:56Z

👍 to channel-like behavior, and if not anything that can fallback when remote resource is unavailable (server down, you're on a plane, etc.) would be great. Kinda lame to have eval fail in those cases. I filed an issue on Nix about this and one solution suggested was to basically (temporarily) bump ttl to infinity (or some high value). Hope this helps and regardless glad your considering this with NUR!

infinisil · 2018-07-12T12:37:45Z

In the latest commit I added support for still being able to use the deprecated callPackage syntax, but it issuing a warning. Now when you try to use such a repository for a NixOS module you'll get this:

trace: WARNING: NUR repository infinisil is using the deprecated callPackage syntax which
will result in infinite recursion when used with NixOS modules
error: infinite recursion encountered, at /home/infinisil/src/nixpkgs/lib/modules.nix:163:28
(use '--show-trace' to show detailed location information)

Also, I added support for specifying an attrset directly in the repos default.nix, so this works too now:

{
  lib = import ./lib;
  modules = import ./modules;
}

I'll put the logic to evaluate a repository into a separate Nix file in future commits, such that the update script won't have to duplicate it.

Mic92 · 2018-07-12T20:54:51Z

default.nix

-
-{ pkgs ? import <nixpkgs> {} }:
+{ nurpkgs ? import <nixpkgs> {} # For nixpkgs dependencies used by NUR itself
+, pkgs ? import <nixpkgs> {} # Dependencies to call NUR repos with


Should we make this argument mandatory and add a error message if not supplied by the user?

The error message could then also include the canonical syntax to import NUR.

Not sure, making the pkgs argument mandatory would mean that import <nur> {} wouldn't work, and you couldn't evaluate it anymore directly, e.g. nix-instantiate '<nur>' -A repos.infinisil.foo wouldn't work anymore.

Should it then default to one import expression for example:

let fallback = import <nixpkgs> {} in { nurpkgs ? fallback, pkgs ? fallback }

I am not sure if this make any difference in terms of performance.

According to @cleverca22 and @LnL7 in #nixos, what you proposed should be faster, so I'll change it to that.

Mic92 · 2018-07-12T21:02:34Z

+1 for adding warnings.

For the sake of simplicity I would prefer if all repo root expression take pkgs by default even if they only define modules. The reason is that repo owners might otherwise by accident use the common pattern:

with import <nixpkgs> {};
{
}

because they don't understand the implication of it yet.
I don't think

{ pkgs }: {
}

is too much boiler code to ask for and makes all modules looks the same (also simpler documentation).
I would appreciate if you also add documentation. I will then notify all repository owner to update their repository.

infinisil · 2018-07-12T21:34:34Z

Yeah that sounds like a good idea. Should we also disallow defaulted arguments though? E.g. { pkgs, lib ? pkgs.lib }: { ... } is quiet useful.

Edit: Yeah I think default arguments should be allowed, they can be used to do stuff like nix-build -A foo --arg someOption true within ones repository. This flexibility would be neat.

infinisil · 2018-07-13T00:06:55Z

I need some help with python (I don't know python well at all): The latest commit needs the path to the new evalRepo.nix file in python, but I'm not sure how to get it.

infinisil · 2018-07-13T00:08:12Z

The update script is now working again with the changes I made. (For some reason eeva's repo is being evaluated every time, but that was like this before my changes as well).

infinisil · 2018-07-13T00:32:54Z

nur/update.py

@@ -169,7 +169,11 @@ def eval_repo(spec: RepoSpec, repo_path: Path) -> None:
        with open(eval_path, "w") as f:
            f.write(f"""
                    with import <nixpkgs> {{}};
-callPackages {repo_path.joinpath(spec.nix_file)} {{}}
+import /home/infinisil/src/NUR/evalRepo.nix {{


This here, I don't think it can stay like this :P

The following should do it:

import {ROOT.joinpath("evalRepo.nix")} {{

Mic92 · 2018-07-13T02:29:35Z

evalRepo.nix

@@ -0,0 +1,20 @@
+{ name


I think to establish best practices, this could go to lib/

Mic92 · 2018-07-13T02:31:06Z

nur/update.py

@@ -184,6 +188,7 @@ def eval_repo(spec: RepoSpec, repo_path: Path) -> None:
            "-I", f"nixpkgs={nixpkgs_path()}",
            "-I", str(repo_path),
            "-I", str(eval_path),
+            "-I", str("/home/infinisil/src/NUR/evalRepo.nix")


If everything would be in lib then "-I", str(ROOT.joinpath("lib")) would cover it.

Mic92 · 2018-07-13T02:32:58Z

If you have trouble get it working, I can take tomorrow a look at it again.

infinisil · 2018-07-13T02:46:08Z

Thanks! Got it figured out, there was a problem of ROOT being just . previously, it needed a .resolve() to make it absolute and therefore work correctly for -I

I'll add some docs in future commits, and will squash commits into reasonable changes when ready for merge

Mic92 · 2018-07-16T15:12:04Z

README.md

-    nur = pkgs.callPackage (import (builtins.fetchGit {
-      url = "https://github.com/nix-community/NUR";
-    })) {};
+    nur = import (builtins.fetchGit "https://github.com/nix-community/NUR") {


I think it is also time to switch to fetchTarball, which is apparently faster then fetchgit - even for incremental updates - since the repository is rather small.

Yeah, will be a bit longer though, but I think that's okay

Mic92 · 2018-07-16T15:14:50Z

README.md

@@ -135,13 +135,13 @@ in stdenv.mkDerivation rec {
 You can use `nix-shell` or `nix-build` to build your packages:

 ```console
-$ nix-shell -E 'with import <nixpkgs>{}; (callPackage ./default.nix {}).inxi'
+$ nix-shell -E '(import ./default.nix { pkgs = import <nixpkgs>{}; }).inxi'


Is the import required here? There is a default nixpkgs import in the file.

Ah, sorry this is for the repository, not for NUR.

Mic92 · 2018-07-16T15:21:17Z

README.md

 nix-shell> inxi
 nix-shell> find $buildInputs
 ```

 ```console
-$ nix-build -E 'with import <nixpkgs>{}; (callPackage ./default.nix {})'
+$ nix-build -E '(import ./default.nix { pkgs = import <nixpkgs>{}; }).inxi'


With the new repository format the following is also possible:

nix-build --arg pkgs "import <nixpkgs> {}" -A inxi

Mic92 · 2018-07-16T15:25:58Z

README.md

 Each repository should return a set of Nix derivations:

 ```nix
-{ callPackage }:
+{ pkgs }:


This might be a bit more convenient for nix-build/nix-shell:

{ pkgs ? import <nixpkgs> {} }:

Nix-shell would then shorten too:

$ nix-shell -E '(import ./default.nix {}).inxi'

Also this might encourage people again to import nixpkgs themselves?

It doesn't matter as long as import <nixpkgs> {} is only used as the default value, since NUR will pass its own pkgs to override it. (I added a section for that in the newest commit).

infinisil · 2018-07-16T20:11:43Z

I added the lib argument to arguments a NUR repo receives because otherwise it would be hard to write other library functions without depending on pkgs, which would bring infinite recursion when those functions are used in certain ways in NixOS modules.

This PR is more-or-less ready now, probably needs some tweaks here and there.

zimbatm

nice

zimbatm · 2018-07-17T22:59:36Z

README.md

-  modules = ./import modules;
+{ pkgs, config, lib, ... }:
+let
+  nur = import (builtins.fetchTarball "https://github.com/nix-community/NUR/archive/master.tar.gz") {};


{ inherit pkgs; }; at the end?

Hmm, I'm not sure, because pkgs isn't actually needed when you just use NUR for modules/overlays/library functions.

Oh I think what would be neat is to change the default pkgs argument used by NUR from import <nixpkgs> {} to throw "NUR didn't receive a pkgs argument". Then usage without a pkgs argument is just fine as long as you don't evaluate it (which is the case when you only need NixOS modules), but as soon as you try to use a package, you get the throw.

zimbatm · 2018-07-17T23:01:43Z

README.md


 ```nix
-{ lib }:
+{ pkgs, lib }:


Is it necessary to pass lib if it's accessible through pkgs.lib?

Using lib without a dependency on pkgs means that it's possible to use library functions (which are built only via lib) in your NixOS config without having to worry about infinite recursion, e.g. when using such a function in an overlay (using pkgs.lib would give inf rec because pkgs depends on overlays).

In an overlay lib from super is supposed to be used and for nixos modules, lib from the function argument is preferred. Would the current approach bypass overlays by reimporting nixpkgs? Are there any other use cases that I have not covered yet?

Would the current approach bypass overlays by reimporting nixpkgs

Not sure what you mean by that, overlays should still work as one would expect. A definition would be like

{ pkgs, lib }: { overlays.foo = self: super: { bar = super.hello.override ...; # super.lib.dosomethingwithlib }; }

Yeah, nixpkgs would get reimported if you were using the lib argument from NUR.

To clarify my previous comment: By reading the writeup on overlays it recommends to use the super argument of the overlay to get access to library functions:

Quote:

super one overlay down in the stack (and base nixpkgs for the first overlay). Use it to access the package recipes you want to customize, and for library functions.

I therefore conclude that using a dedicated lib from our own import in overlays and modules is neither necessary nor best practice. I think this is a pitfall worth documenting though.

Hmm yeah, actually the lib argument really doesn't have a lot of uses other than for using it for library functions, and even then, it will only be a problem in NixOS in certain not even common cases. So maybe it would be best to just not provide lib for now, only add it later if problems arise.

zimbatm · 2018-07-17T23:03:40Z

default.nix

 let
-  inherit (pkgs) fetchgit fetchzip callPackages lib;
+  inherit (nurpkgs) fetchgit fetchzip lib;


maybe add a note that the builtins have issues with TTL

Probably not at this line of code, but yeah I can add that to the readme :)

Is possible to prevent garbage collection by linking used tarballs in a profile?

I don't think so

infinisil · 2018-07-18T19:04:14Z

I rebased on master, and squashed all commits into 3, one for docs, one for nix and one for python.

Noteworthy changes are:

Added some more headers to the readme and a tiny restructure
See below vv

infinisil · 2018-07-18T19:05:06Z

README.md

  };
 }
 ```

+### Pinning
+
+Using `builtins.fetchTarball` without a sha256 will only cache the download for 1 hour by default, so you need internet access almost every time you build something. You can pin the version if you don't want that:


This section is new

Update I have not yet understand the full consequence of a fixed-input derivation: I have a non-stable URL in configuration.nix that I gave a checksum and nix is testing it from time to time and complains if the checksum changes. On the other hand I never had evaluation errors because the file is not available. Does this only works in my case because the referenced file is part of system profile closure or does this also apply to imported nix expression?

For fixed output derivations (ones you give a hash), Nix will first check if a file with that hash is already in the store, and use that if there is. It will only try to fetch it when no such hash could be found. After the fetch it will only succeed in adding the download if the hash you gave matches the one it calculated. If it doesn't match, it fails. The fetchers from nixpkgs will also output the correct hash on a mismatch.

How does nix decide, when to delete fixed-input derivations in this case?

I think the only way it deletes them is garbage collection.

infinisil · 2018-07-18T19:06:15Z

default.nix

@@ -1,7 +1,10 @@
+{ nurpkgs ? import <nixpkgs> {} # For nixpkgs dependencies used by NUR itself
+  # Dependencies to call NUR repos with
+, pkgs ? throw "NUR call didn't receive a pkgs argument, but the evaluation requires it."


This is new, I think this should be okay, there's no need to provide an implicit pkgs

Also coincides with requiring a pkgs before this PR, as it was pkgs.callPackage (fetchGit ...)

This change is great because it will help users when using NUR wrong. I would be cool if it also contains a small example how the fix the error.

Mhm. It might be not only the user to blame, the repo author could also use it incorrectly... tricky stuff.

I can add a note that says it could be an error on either side.

Mic92 · 2018-07-18T22:28:36Z

README.md

+  # Get the revision by choosing a version from https://github.com/nix-community/NUR/commits/master
+  url = "https://github.com/nix-community/NUR/archive/3a6a6f4da737da41e27922ce2cfacf68a109ebce.tar.gz";
+  # Get the hash by running `nix-prefetch-url --unpack <url>` on the above url
+  sha256 = "04387gzgl8y555b3lkz9aiw9xsldfg4zmzp930m62qw8zbrvrshd";


Future work (not in the scope of this pr) - automate pinning updates.

Mic92 · 2018-07-18T22:36:01Z

README.md

+```nix
+{ pkgs, config, lib, ... }:
+let
+  nur = import (builtins.fetchTarball "https://github.com/nix-community/NUR/archive/master.tar.gz") {};


It is easy to shadow nur by using environment.systemPackages = [ nur.repos.mic92.inxi ]; instead of environment.systemPackages = [ pkgs.nur.repos.mic92.inxi ];.
In this case pkgs in NUR will be undefined and the error message you added is thrown.
Maybe the example should not called it nur for overlays/modules to avoid this namespace collision?
The alternative could be also to make nur a nixos module (also it is probably not possible to dynamically inject imports and overlays?) - maybe a function that returns a nixos module could work.

The alternative could be also to make nur a nixos module

Yeah I thought of that! Would actually solve this problem rather elegantly: Users could add something like imports = [ (import <nur/modules> {}) ] (replace nur with the fetch command) exactly once to their nixos config.

To make this work, NUR should wrap every repositories modules under an enable option. So e.g. when I now want to use your foo module (which you declared in modules.foo), I'd do nur.mic92.foo.enable = true. This would work like this, and I might implement this in a future PR. For now this more hacky solution should be fine, especially since it can be forwards compatible.

Oh and regarding the nur attribute name, I think changing it to nur_for_modules would work well.

True, the nixos module can be also implemented in future. I also intentionally put repos into sub namespace so we can put more into the top-level hierarchy.

Tracked here: #43

s/nur_for_modules/nur-modules/g

Maybe nur-no-pkgs? Because the example there also uses overlays with it.

Mic92 · 2018-07-18T22:43:08Z

Sorry for being extra nitpicky and critical on this pull request, but since it requires changes for both users and maintainers I would like to keep the revisions on the API low.

infinisil · 2018-07-18T22:53:20Z

Sorry for being extra nitpicky and critical on this pull request

No problem, I'm also always very much like this on non-trivial nixpkgs PR reviews :)

infinisil · 2018-07-18T23:53:54Z

Added a super descriptive error message which includes the repository the error originates from.

Mic92 · 2018-07-19T21:52:56Z

Feel free to merge this, if you think it is ready. Please also notify all repo users so they can update accordingly.

This is essential to get modules in NUR to work. By taking a separate argument for NUR's nixpkgs (for fetchgit, fetchzip and lib), we don't need to evaluate the nixpkgs used for repos. This also implies that you won't be able to `callPackage` NUR anymore, and instead you'll have to use `import (builtins.fetchGit ".../NUR") { inherit pkgs; }` instead. Doing this also prevents the evaluation of pkgs. In case of NixOS, this pkgs depends on your whole config, which is the source of the recursion. Evaluating this at the last possible moment is key. This also means that you won't be able to take package arguments in a repo definition, you instead get just `pkgs`, also to avoid evaluation of it. An error will be thrown when pkgs was required for evaluation but wasn't passed to the NUR import The old callPackage syntax will still be supported albeit with a warning Also repos receive a lib argument, Using this lib instead of pkgs.lib makes it possible to define library functions that use other library functions without depending on pkgs -> should prevent some infinite recursion cases for NixOS module usage.

- changes for new style of invoking NUR (passing pkgs argument) - Using fetchTarball instead of fetchGit for speed - Add more sections to readme

infinisil · 2018-07-20T02:41:56Z

Made some minor adjustments and fixes:

lib doesn't get passed to the repo, people can use pkgs.lib. We can pass more arguments later if the need arises (it probably won't)
Updated python script to latest changes
Having the "pkgs not passed" warning work with the deprecated syntax.

I tested everything now and I think it's ready. I'll merge this today/tomorrow and open an issue mentioning all people that need to update their repo.

zimbatm

LGTM! It's taken shape rather nicely compared to the initial version

zimbatm · 2018-07-20T10:43:34Z

README.md

-    nur = pkgs.callPackage (import (builtins.fetchGit {
-      url = "https://github.com/nix-community/NUR";
-    })) {};
+    nur = import (builtins.fetchTarball "https://github.com/nix-community/NUR/archive/master.tar.gz") {


Sorry I missed why using callPackage was an issue. Both are fine for me

Because when you do pkgs.callPackage, this needs to evaluate pkgs (to get the attribute), which requires evaluating all overlays and the config (because they're passed to the nixpkgs import), but those overlays can be defined in all modules. So if you want to imports = [ nur.repos.infinisil.modules.foo ], this gives infinite recursion, because to evaluate the modules it needs to evaluate pkgs!

Thanks, that makes a lot of sense

fgaz · 2018-07-21T18:51:59Z

Sorry for saying this after the merge, but I think packages should have been in a separate attribute too, since now there's no way to only get packages from a NUR without doing this

infinisil · 2018-07-22T13:01:56Z

@fgaz Yeah I thought of that too. Doesn't really have anything to do with this PR though, it was the same before. Maybe open an issue regarding that

tilpner · 2018-07-22T13:09:31Z

@fgaz I have a pkgs attribute in my nur-packages, additional to having them as top-level attributes. I use that to overlay just my packages locally (lib would cause problems if overlayed naively).

Do you intend for something like this to become convention, or do you want all top-level packages to be gone?

fgaz · 2018-07-22T13:45:50Z

@tilpner yeah that's definitely better than my filter...

I still think the top level should only be the four sets pkgs, lib, modules, and overlays though.

I opened an issue about it: #51

NixOS module support: Separate NUR nixpkgs from repos nixpkgs, avoid callPackages

…hub_actions/actions/checkout-v2.3.3 Bump actions/checkout from v2.3.2 to v2.3.3

infinisil changed the title ~~Separate NUR nixpkgs from repos nixpkgs, avoid callPackages~~ NixOS module support: Separate NUR nixpkgs from repos nixpkgs, avoid callPackages Jul 9, 2018

infinisil changed the title ~~NixOS module support: Separate NUR nixpkgs from repos nixpkgs, avoid callPackages~~ [WIP] NixOS module support: Separate NUR nixpkgs from repos nixpkgs, avoid callPackages Jul 9, 2018

Mic92 reviewed Jul 12, 2018

View reviewed changes

Mic92 mentioned this pull request Jul 12, 2018

Distributing an overlay with nur #10

Closed

infinisil commented Jul 13, 2018

View reviewed changes

Mic92 reviewed Jul 13, 2018

View reviewed changes

evalRepo.nix Outdated

@@ -0,0 +1,20 @@

{ name

Copy link

Member

Mic92 Jul 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think to establish best practices, this could go to lib/

Mic92 reviewed Jul 13, 2018

View reviewed changes

Mic92 reviewed Jul 16, 2018

View reviewed changes

zimbatm reviewed Jul 17, 2018

View reviewed changes

infinisil force-pushed the modules branch 3 times, most recently from 71e8b18 to 0d3917b Compare July 18, 2018 18:59

infinisil commented Jul 18, 2018

View reviewed changes

Mic92 reviewed Jul 18, 2018

View reviewed changes

Mic92 mentioned this pull request Jul 18, 2018

Make NUR a nixos module #43

Open

infinisil force-pushed the modules branch from 894e8dd to f1ba84f Compare July 20, 2018 02:08

infinisil added 3 commits July 20, 2018 04:36

Update python script for new syntax

270aa18

Update docs

993df1d

- changes for new style of invoking NUR (passing pkgs argument) - Using fetchTarball instead of fetchGit for speed - Add more sections to readme

infinisil force-pushed the modules branch from f1ba84f to 993df1d Compare July 20, 2018 02:37

zimbatm approved these changes Jul 20, 2018

View reviewed changes

infinisil changed the title ~~[WIP] NixOS module support: Separate NUR nixpkgs from repos nixpkgs, avoid callPackages~~ NixOS module support: Separate NUR nixpkgs from repos nixpkgs, avoid callPackages Jul 20, 2018

infinisil merged commit 0dffdf2 into nix-community:master Jul 20, 2018

infinisil deleted the modules branch July 20, 2018 18:23

infinisil mentioned this pull request Jul 20, 2018

Repository syntax change #45

Closed

9 tasks

fgaz mentioned this pull request Jul 22, 2018

Move top-level packages to a pkgs attribute #51

Open

infinisil mentioned this pull request Nov 10, 2018

.github/CODEOWNERS: Add infinisil to NixOS modules NixOS/nixpkgs#50118

Merged

9 tasks

milahu pushed a commit to milahu/NUR that referenced this pull request Aug 5, 2023

Merge pull request nix-community#27 from Infinisil/modules

d3ca724

NixOS module support: Separate NUR nixpkgs from repos nixpkgs, avoid callPackages

milahu pushed a commit to milahu/NUR that referenced this pull request Aug 6, 2023

Merge pull request nix-community#27 from nix-community/dependabot/git…

e3d4f56

…hub_actions/actions/checkout-v2.3.3 Bump actions/checkout from v2.3.2 to v2.3.3

NixOS module support: Separate NUR nixpkgs from repos nixpkgs, avoid callPackages #27

NixOS module support: Separate NUR nixpkgs from repos nixpkgs, avoid callPackages #27

Conversation

infinisil commented Jul 9, 2018

Mic92 commented Jul 11, 2018

Mic92 commented Jul 11, 2018

dtzWill commented Jul 11, 2018

infinisil commented Jul 12, 2018

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

Mic92 commented Jul 12, 2018 • edited Loading

infinisil commented Jul 12, 2018 • edited Loading

infinisil commented Jul 13, 2018

infinisil commented Jul 13, 2018

Choose a reason for hiding this comment

Mic92 Jul 13, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mic92 commented Jul 13, 2018

infinisil commented Jul 13, 2018

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

infinisil Jul 16, 2018 • edited Loading

Choose a reason for hiding this comment

infinisil commented Jul 16, 2018

zimbatm 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

Choose a reason for hiding this comment

Mic92 Jul 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infinisil commented Jul 18, 2018 • edited Loading

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

Mic92 Jul 18, 2018 • edited Loading

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

Mic92 Jul 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mic92 Jul 18, 2018 • edited Loading

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

Mic92 commented Jul 18, 2018 • edited Loading

infinisil commented Jul 18, 2018

infinisil commented Jul 18, 2018

Mic92 commented Jul 19, 2018 • edited Loading

infinisil commented Jul 20, 2018 • edited Loading

zimbatm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mic92 commented Jul 12, 2018 •

edited

Loading

infinisil commented Jul 12, 2018 •

edited

Loading

Mic92 Jul 13, 2018 •

edited

Loading

infinisil Jul 16, 2018 •

edited

Loading

Mic92 Jul 18, 2018 •

edited

Loading

infinisil commented Jul 18, 2018 •

edited

Loading

Mic92 Jul 18, 2018 •

edited

Loading

Mic92 Jul 18, 2018 •

edited

Loading

Mic92 Jul 18, 2018 •

edited

Loading

Mic92 commented Jul 18, 2018 •

edited

Loading

Mic92 commented Jul 19, 2018 •

edited

Loading

infinisil commented Jul 20, 2018 •

edited

Loading

infinisil Jul 20, 2018 •

edited

Loading