md2gemini: init at 1.8.1

[KAction]

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs 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/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[SuperSandro2000]

I think it would be clearer if we converted the current default into a generic nix and created a 0.8.nix and a 2.nix file.

[KAction]

Did it same way as postgresql do.

[SuperSandro2000]

Suggested change

	propagatedBuildInputs = [ mistune_2 cjkwrap wcwidth ];
	checkInputs = [ pytest ];

[SuperSandro2000]

Suggested change

	{ lib, buildPythonPackage, fetchPypi, mistune_2, cjkwrap, wcwidth, pytest }:
	{ lib, buildPythonPackage, fetchPypi, mistune_2, cjkwrap, wcwidth, pytestCheckHook }:

[SuperSandro2000]

That causes an eval error.

[KAction]

That does not belong here, removed.

[KAction]

Looks like I applied all suggestions.

[SuperSandro2000]

@ofborg eval

[KAction]

Okay, now @ofborg is happy.

[SuperSandro2000]

Missing maintainer.

[KAction]

It was this way before.

[KAction]

Okay, I added pythonImportsCheck to mistune, but I'd rather not assume maintainership of every indirect dependency I touch. Wh

[SuperSandro2000]

Okay, I added pythonImportsCheck to mistune, but I'd rather not assume maintainership of every indirect dependency I touch. Wh

The problem is that if your dependencies are not maintained they are potentially in a worse state but it seems like mistune is used in a lot more packages.

I think adding the imports check to mistune triggered the mass rebuild. We really want to have one if there are not tests because otherwise the package can silently break. I think the best solution would be to merge this PR into staging because if we split the change out we force a merge conflict which someone would need to resolve. Let me know if thats a problem for you.

[SuperSandro2000]

other than that the ordering could be a bit more standard LGTM if rebased to staging

[SuperSandro2000]

other than that the ordering could be a bit more standard LGTM if rebased to staging

[KAction]

Yes, sure. Let's merge it into staging.

[SuperSandro2000]

/rebase staging

[github-actions]

Rebased, please reopen the pull request to restart CI