Clean up pyproject.toml and build pipeline

[emilykl]

Link to issue

Closes #5537

Description of change

• Switch build backend from setuptools to hatch
  • hatch is distributed by PyPA and has a number of advantages compared to setuptools, including being newer and more modern
• Update pyproject.toml config to work with hatch, and remove unused config sections
  • Remove MANIFEST.in file, since it's only required by setuptools, not needed for hatch
• Update js/package.json to reflect the correct version number matching plotly.py version, which we've forgotten to do for the last few releases
• Update RELEASE.md instructions to add step to update version number in js/package.json
• Remove keys from js/install.json file which I believe are not needed

NOTE: The build command remains the same: python -m build .

Demo

python-m-build.mov

When running python -m build . locally, the output should look like the above.

Testing strategy

I've added a CI step in .github/workflows/check-js-build.yml to check that the version number in pyproject.toml matches the version number in js/project.json, which should prevent the two from getting out of sync again.

Show success case

Show failure case

No additional unit testing is needed: The CI already runs `python -m build .` , so if that step fails then we know something is wrong.

However, we should verify manually that the resulting build is the same before and after these changes.

This can be done by checking out this branch, running python -m build ., and comparing the .tar.gz and .whl files to the official 6.6.0 release artifacts.

Additional information (optional)

Because we manually pre-build the assets for the JupyterLab extension (by running npm run build from the js/ directory, as documented in the CONTRIBUTING.md), we do not use any of the hatch build hooks settings in the pyproject.toml, so this PR removes them.

The existing .github/check-js-build.yml step builds the lab extension in CI and ensures that the output matches the build artifacts in plotly/labextension/.

• Note: There was a bug where the build artifacts in the CI would sometimes differ from the locally-built artifacts in an insignificant way. I seem to have inexplicably fixed this by adding a couple of debug flags to the jupyter labextension build command in the project.json. I'm not convinced it's fully gone, though.

I don't like that this setup requires updating the version number in two places. But package.json doesn't support dynamic version numbers, so the only way to set up a single source of truth would be for the package.json to be the single source of truth, and pyproject.toml to load that version number dynamically. I don't like that for a Python project. But open to suggestions.

Guidelines

• I have reviewed the pull request guidelines and the Code of Conduct and confirm that this PR follows them.
• I have added an entry to the changelog if needed (not required for documentation PRs).

[emilykl]

fyi @franred this is the PR I mentioned last week!