I disagree. PyPI is basically a packaging environment, so using the tarballs from there would mean we are then subject to the curation decisions by the people who package the PyPI releases before we even get the sources for the package (which may or may not be the upstream developers).

If someone who isn't the developer of a Python package, nor a part of their team, is uploading packages to PyPI, I would personally view that as a major security vulnerability.  Doubly so if they are making decisions inconsistent with the developers'.

The updated packaging guidelines describe the need for PyPI parity, which arises from a security issue created by the fact that Python packaging tools use a flat namespace.  Fedora packages should be expected to provide the same content that they would if they were installed through pip.  There are certainly going to be cases where the upstream tarballs lack required content, but in my opinion, we should treat that as a bug and work with the developers to ensure that the release tarballs are usable in the future.

Additionally, using the GitHub repo as the source of the package would seem to fit the spirit behind the packaging guidelines more (https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/) - where it says "For the Fedora packager, this means that sources used to build a package should be the vanilla sources available from upstream."

I don't think those guidelines require us to reduce upstream release process to simply "git clone && tar".  And, regardless, "using the GitHub repo" doesn't solve the problem at hand, which is that a number of developers specifically tag releases built directly from the git repo as "dev" releases, which might cause rpm dependency resolution problems later.