python3Packages.listparser: init at 0.20

[uninsane]

this package was previously available via gnome-feeds.passthru.listparser but was removed when no longer needed by gnome-feeds. make it available as a standalone package, because the OPML lists it works with are usable by many (other) feed readers.

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

---

Add a 👍 reaction to pull requests you find important.

[SuperSandro2000]

Suggested change

	listparser = toPythonModule (callPackage ../development/python-modules/listparser { });
	listparser = callPackage ../development/python-modules/listparser { };

[SuperSandro2000]

Suggested change

	pypaBuildHook
	pypaInstallHook

[SuperSandro2000]

Suggested change

	stdenv.mkDerivation (finalAttrs: {
	buildPythonPackage {

[h7x4]

@SuperSandro2000 You might want to read earlier comment threads here for context

[natsukium]

@SuperSandro2000 You might want to read earlier comment threads here for context

There is no need. See #271597 (comment)

[SuperSandro2000]

@SuperSandro2000 You might want to read earlier comment threads here for context

After finding the resolved review thread and thinking a bit about it, I could finally understand why the change was done. The justification for it is not sufficient and just hacks around our future plans, making things more complicated than they need to be. The package here should and must use buildPythonPackage and I personally do not have a preference if the new or old names are used but it is probably better to use the newer ones.

That there is a personal disliking for the naming doesn't allow that we make a special exception for a package where there is no reason to do so. I also had other naming suggestions in the PR where it was done but matching upstreams python code is a good justification.

[uninsane]

@natsukium thanks for taking the time to weigh in: that did clear up the direction of python packaging in nixpkgs for me.

i understand the limitations with propagatedBuildInputs. i don't quite understand the need for build-system yet, after reading the discussions i could reach from #271597 (comment). but that's OK: it's clear enough that the direction of these things is settled. OTOH the idioms i use when packaging for myself v.s. packaging python libraries for nixpkgs are different enough now (and will grow more different in the future) that trying to do both doesn't make a whole lot of sense.

unless something pops up that i really, really want to share, i'm going to keep it simple and just package these smaller libraries locally (where they're still public, at least, just without the accessibility/reach of nixpkgs).