cc @domenkozar @grahamc @copumpkin @manveru @garbas

So far it only creates the JSON data. License parsing is something for later.

buildPythonPackage now uses by default PyPI. If only a name is given, the latest version is used. If also a version is given, then that version is used. When a src is given, that is used instead.

If this proves to be too gnarly, I was thinking of a more lightweight option, which is to introduced a new fetchPyPI fixed-output derivation that we can use for all our src attributes, without changing anything else. The fetcher would know how to figure out the correct URL and but would otherwise still produce the same tarballs as we were getting before.

A function like fetchPyPI that obtains the url and hash via the JSON API as I do now is indeed a much lighter-weight option. The only downside is having to set the version manually. And it would be a bit more verbose.

Or we could have fetchPyPI and also still generate a list with meta-data and available versions per package. I can also leave buildPythonPackage untouched and create instead say buildPyPIPackage that uses buildPythonPackage.

What we need is to find an agreement on what kind of data we want to have in NIxpkgs and what not.
And as I think @copumpkin wrote somewhere else as well: do we want to have all packages, or a curated list. In case of the latter it would make sense having to explicitly set the version.

@FRidh explicitly picking the version doesn't seem overly onerous, since we do it everywhere else. The other question is a much bigger one though 😄

@copumpkin actually, having a fetchPyPI would solve the url scheme change of PyPI, but you would still need to use say nix-prefetch-pypi to obtain the hash and put it in your code. That's something I would like to get rid of.

(fetchPyPI could obtain the hash as I wrote in my previous post, but that would take away most of the use of the hash. A certain Nixpkgs revision wouldn't be unique anymore then either, so let's not do that.)

fetchPyPI:
triton/triton@ffcbbf7

#15007 is an alternative to the PR where I use a separate function, buildPyPIPackage, to build a PyPI package. I think that is a better solution.