crater: init at 4.2.0

[DieracDelta]

Motivation for this change

Note: opening this on behalf of @MatthewCroughan

This adds a NixOS module and package for Crater, an invoicing app. Now Nix (ab)users can finally get paid!

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[fabianhjr]

Should add this information. From a quick glance seems like:

• Homepage: https://craterapp.com/
• License: https://spdx.org/licenses/AAL.html
• Description: "Free & Open Source Invoice App for Freelancers & Small Businesses" (From GitHub project)
• Maintainers, you should add yourself or someone else as maintainer of this nix expressions.

[fabianhjr]

AAL seems to be missing from https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix, it should be added there.

[MatthewCroughan]

There is an issue with Crater since it stores the path to laravel "storage" in the database.

[nix-shell:~]# strings /var/lib/crater/database.sqlite | grep nix
33local_privateSYSTEMlocal"{\"root\":\"\\\/nix\\\/store\\\/64l9q7imbhhvvc4x07n1qmrdvwbwwimq-crater-4.2.0\\\/storage\\\/app\",\"driver\":\"local\"}"2021-10-23 01:53:532021-10-23 01:53:53
'33local_publicSYSTEMlocal"{\"driver\":\"local\",\"root\":\"\\\/nix\\\/store\\\/64l9q7imbhhvvc4x07n1qmrdvwbwwimq-crater-4.2.0\\\/storage\\\/app\\\/public\",\"url\":\"http:\\\/\\\/crater.test\\\/storage\",\"visibility\":\"public\"}"2021-10-23 01:53:532021-10-23 01:53:53

This path resolves to /var/lib/storage, but sadly it uses the absolute path to the Nix store. I think this is because the PHP function that creates this path is not following symlinks.

This means that changes to the dataDir option of the module are not going to work upon a rebuild.

Despite this, I think the module is in a good working state, and it is as good as it is going to get without radically changing the way the program works.

Is it possible that @aanderse could review this?

[aanderse]

gitea used to do something similar 😟

Very unfortunately, you should probably use the sqlite binary to update this value in a script that runs on rebuilds... think about what happens the next time you run the garbage collector 🤯 I'm glad you caught this!

[MatthewCroughan]

@aanderse The user can use mysql, in that case this is unfixable. They could be using any database software they want. We can only fix this for sqlite.

[MatthewCroughan]

As a workaround for the database issue, I currently use the following. It's a script that:

1. Waits until database.sqlite is non-zero AND file_disks exists.
2. Pipes the json string from file_disks into jq
3. Creates a new json string with the incorrect path replaced with the dataDir:
4. Uses sqlite3 to UPDATE this value in the database

  systemd.services.phpfpm-crater.postStart = ''
    until [[ -s ${config.services.crater.dataDir}/database.sqlite && $(${pkgs.sqlite}/bin/sqlite3 ${config.services.crater.dataDir}/database.sqlite "select credentials from file_disks;") ]] 
    do
      sleep 1
      echo "DATABASE IS BLOODY EMPTY"
    done
    STORAGE_PUBLIC=`${pkgs.sqlite}/bin/sqlite3 ${config.services.crater.dataDir}/database.sqlite "select credentials from file_disks where id=1;" | ${pkgs.jq}/bin/jq -r | ${pkgs.jq}/bin/jq '.root = "${config.services.crater.dataDir}/storage/app/public"' | ${pkgs.jq}/bin/jq -c`
    STORAGE=`${pkgs.sqlite}/bin/sqlite3 ${config.services.crater.dataDir}/database.sqlite "select credentials from file_disks where id=2;" | ${pkgs.jq}/bin/jq -r | ${pkgs.jq}/bin/jq '.root = "${config.services.crater.dataDir}/storage/app"' | ${pkgs.jq}/bin/jq -c`
  
    ${pkgs.sqlite}/bin/sqlite3 ${config.services.crater.dataDir}/database.sqlite "UPDATE file_disks SET credentials = '$STORAGE_PUBLIC' where id=1;"
    ${pkgs.sqlite}/bin/sqlite3 ${config.services.crater.dataDir}/database.sqlite "UPDATE file_disks SET credentials = '$STORAGE' where id=2;"
  '';

[aanderse]

I should probably take a look at this again. I've actually been using crater for some time now... but imperatively installed under something like /var/www/crater. Definitely a more challenging application to "properly" package for NixOS.

[MatthewCroughan]

@aanderse I would avoid Crater. It is not the correct way to manage your taxes, or expenses. It will only lead you to accounting troubles, since it is not modelling accounting correctly. Instead, I started using Hledger which correctly models accounting. In addition to Crater making many mistakes regarding accounting, it also has many software engineering mistakes such as the ones we've already discussed and ran into in this thread. Hledger has a web interface that isn't as pretty, that is available in NixOS already via services.hledger-web.

[onny]

Trying to update it to the latest version and testing it #200379
@DieracDelta feel free to these incorporate changes into your PR

[MatthewCroughan]

@onny There are bound to be a lot of runtime bugs that you cannot count on discovering, without using the software. It gets worse with each release.

[onny]

That sounds bad. I'll give it a try and see how it does

[MatthewCroughan]

Just to be clear, I'm talking about bugs unique to Nix because of the read-only store. And we still do not have a solution to the problem outlined in #141822 (comment) where there are illegal references to the /nix/store being stored in the database. Which is a choice of the program that we can't override without patching the source code. It seems like a lot of time to spend on this (in my view) bad software.

[aanderse]

@aanderse I would avoid Crater. It is not the correct way to manage your taxes, or expenses.

Thanks for the advice @MatthewCroughan. Fortunately I only use a minimal feature set and don't rely on it for anything which is impacted by what you said. I'll keep it that way now too. 🙇‍♂️

@onny if you're still set on pushing through with this software I'll try to give this some thought. Let me know.