Why not add this to python-packages?

Nothing else depends on it, and the package also hasn't been updated in a good while (last commit on the upstream repo is from September 2017). I was under (perhaps wrong) impression Python maintainers are reluctant to accept a new package like this and making it a private / vendored package was preferred.

That makes sense. I think that's a pretty good reason for keeping it private.

Could you add a comment why this is disabled?

Default checkPhase doesn't seem to do anything (Ran 0 tests..). I'm not familiar with Python ecosystem at all, perhaps I'm just missing a checkInputs dependency but I simply don't know how to properly invoke the check phase so that tests are ran (the tests folder and its contents are present in the PyPI archive).

Hmm, you might need to explicitly specify checkPhase.

I think this is in context of listparser. I just added a commit that runs the tests based on what I found in tox.ini. The test suite however fails :-(. Maybe I'm missing something obvious but based on the output I really don't understand why.. Any ideas what's happening?

NVM, I was looking at the development branch of the package instead of the tagged release, test should now run and pass with the commit I just pushed.

https://xkcd.com/1179/

Except for the version format, this looks good to me. Thanks @pbogdan!

I've seen other packages use python3Packages.callPackage so python packages are passed as arguments to the expression. I prefer it over accessing them through python3.pkgs / python3Packages, but I'm not sure if it's the generally accepted approach.

The opinions are somewhat mixed, slightly leaning to avoiding it. The main disadvantage is that it just shifts the qualified accessor to normal packages, that is, we would need to use pkgs.meson…

I've used it before without needing to qualify normal packages:

• nixpkgs/pkgs/development/tools/cmake-language-server/default.nix

  Line 3 in 93ebfda

  , cmake, pytest, pytest-datadir

• nixpkgs/pkgs/development/python-modules/debugpy/default.nix

  Line 2 in a408cd9

  , substituteAll, gdb

There are sometimes conflicts between normal packages and python packages. You would want to use pkgconfig or meson from all-package.nix but you would get the python package with the same name. (pkg-config now has a different name but the legacy alias still conflicts.) And when https://pypi.org/project/cmake/ is packaged, your package breaks.

Ah, good point 😄. I will fix that next update.

It might be better to move this into pkgs/development/python-modules/listparser to separate this from Gnome Feeds, and so it can be used by other packages in the future.

I would also recommend directly pulling the sources from https://github.com/kurtmckee/listparser to run the tests.

Correction: It looks like the tests are included in the pypi package, so you might not need to pull the sources directly from the git repo.

@worldofpeace You asked me to do this before for #64705. What do you suggest here?

That is the convention when obtaining a git commit instead of tag, see https://nixos.org/nixpkgs/manual/#sec-package-naming. It is also controversial: #88023 (comment)

I just noticed that @pbogdan mentioned that the latest release version doesn't work, so I deleted my comments related to it.

That is the convention when obtaining a git commit instead of tag, see https://nixos.org/nixpkgs/manual/#sec-package-naming. It is also controversial: #88023 (comment)

One issue might be that r-ryantm might not update files with multiple hashes in them.

I think now it's impossible to override it in case it fails to build.. You should also be able to use callPackage instead which is a bit more versatile - you won't need inherit lib python3;. If we would like to not add it to python-packages.nix, we can put in the arguments list:

, listparser ? callPackage ./listparser.nix { }

And then inside the feeds expression, use passthru = { inherit listparser; }; - this will expose it and allow it to be overridden in case it fails to build.

Can you explain why it should go into passthru? I don't quite see how that's going to help with overriding.

With the passthru, one should be able to:

self: super: {
  feeds-with-different-listparser = super.feeds.override {
    # No need to use the `passthru` attribute, but it helps the usage be clear
    listparser = super.feeds.passthru.listparser.overrideAttrs(oldAttrs: {
      /* src = ...; */
    });
  };
}