Update package metadata

[ofek]

Description

Fixes #1662

Hello there! The Python packaging ecosystem has standardized on the interface for build backends (PEP 517/PEP 660) and the format for metadata declaration (PEP 621/PEP 631). As a result, the execution of setup.py files is now deprecated.

So, I'm spending my free time updating important projects so that they are modernized and set an example for others 😄

Summary of changes

This implements PEP 621, obviating the need for setup.py and MANIFEST.in. The build backend hatchling (of which I am a maintainer in the PyPA) is now used as that is the default in the official Python packaging tutorial. Hatchling is available on all the major distribution channels such as Debian, Fedora, Arch Linux, conda-forge, Nixpkgs, Alpine Linux, FreeBSD/OpenBSD, Gentoo Linux, MacPorts, OpenEmbedded, Spack, MSYS2, etc.

Notes

• All readme image paths are fixed (see current https://pypi.org/project/gradio/)
• The source distributions on PyPI are erroneously shipping a build artifact *.egg-info from python setup.py develop; this is now fixed
• The binary distributions (wheels) on PyPI are unintentionally shipping the test directory ever since Add requirements.txt and test_files to source dist #1817 which clashes with other installed packages; this is now fixed and the wheel is ~1mb smaller

Future

• We could ship optional wheels compiled with Mypyc, as Black recently did

Checklist:

• I have performed a self-review of my own code
• My code follows the style guidelines of this project
• I have commented my code in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[ofek]

PEP 660 (pip install -e) landed in https://pip.pypa.io/en/stable/news/#v21-3

[abidlabs]

Thank you @ofek for the contribution. To be honest, I am not very familiar with hatchling so we will need to look into this and make sure this does not break any of our ci/deployment scripts. One question for you -- will this PR still allow us editable installs (pip install -e .) if setup.py is removed?

What are your thoughts @freddyaboulton @aliabid94 @dawoodkhan82?

[ofek]

will this PR still allow us editable installs (pip install -e .) if setup.py is removed?

Yup! Since v21-3

[freddyaboulton]

Thank you for the contribution @ofek ! I had filed an issue to track work similar to this #1662 and I'm glad you beat us to it.

I don't know that much about hatchling either - I was thinking we'd use setuptools when I filed #1662 - but I'll check this out this week so I can see how it works and if this PR accidentally breaks anything in our current build process. \

[ofek]

Happy to help! Please let me know any feedback you may have for Hatchling. As I mentioned to someone else earlier today, some of the discussion about making that the new default starts here pypa/packaging.python.org#1031 (comment)

I'll quote Henry who expressed the common sentiment:

Which backend should be the "only" backend? tools.setuptools is still experimental and there are a lot of older pre-PEP 621 copies of it around, and it's large and full of legacy cruft still, causing slower builds and harder error messages - it can be powerful, but it seems to be an overkill for newcomers and simple Python only projects. Flit is lite and fast, with simple error messages, but a crippled file include/exclude system that won't include LICENSE.md by default but will include __pycache__ folders. Hatchling seems to be a nice balance, with reasonable defaults & nice error messages. For a nice newcomer experience, I think Hatchling is likely best.

Essentially. I did my best to learn the best and worst parts of other backends in order to implement Hatching, which is why it Just Works ™️ while at the same time being simpler to configure and easier to extend.

[freddyaboulton]

@ofek There's a gradio/templates directory that's created when the front-end code is built. We need to include it in the source and wheel distribution. Can you please make the change? Thank you!

[ofek]

Sure! It doesn't by default because of .gitignore:

# JS build
gradio/templates/cdn
gradio/templates/frontend

[ofek]

Done

[freddyaboulton]

Thanks @ofek ! 😄

@abidlabs I tested it out today and I think everything is working. I uploaded version 3.3b1 so you can test it out. See it here. This is what I tested:

• Editable install works as expected
• gradio command still works
• %blocks jupyter cell magic still works. See the colab below
• Running on spaces still spaces works. See here
• Running on colab still works. See here.
• The docs can still be built and the demos work as expected

- [ ] Changes to the front-end show up in the editable install.

Anything else we should test? Otherwise looks good to me. CC @aliabd @aliabid94

[aliabid94]

LGTM, thanks @ofek! thanks for testing @freddyaboulton

[abidlabs]

Awesome @ofek and @freddyaboulton! Very comprehensive testing, LGTM