Towards pyproject.toml from setup.py?

[consideRatio]

In jupyterhub/kubespawner#666 I transitioned kubespawner to no longer use setup.py but instead rely entirely on pyproject.toml together with PyPA's hatchling build system, and I was proposing this for oauthenticator.

I think using pyproject.toml has been successful so far, and various build systems has been able to help us build javascript bundles etc as well for example in jupyterhub/jupyter-server-proxy that bundles with a jupyterlab extension.

Is there agreement for me to transition misc simpler projects without complicated builds towards pyproject.toml from setup.py, using hatchling as a build system? To my knowledge, there isn't a notable upside practically yet, but I understand pyproject.toml as the direction the python ecosystem is moving so I'd like to follow it.

[minrk]

I think the tooling is a bit nicer, and I'd recommend it for new projects. I think it's worth doing for things like jupyter-server-proxy that build a jupyterlab extension, since the plugins the jupyterlab team have provided for doing exactly that are really nice. For any existing package, I'd call it a very low priority and a recommendation but not a policy, since there isn't any real benefit to switching once you have something that already works - most of the benefit is in putting it together in the first place. I wouldn't object to any PR of someone decided they did want to put in the time, but almost everything else is higher priority, I think. For packages that don't have an npm build step (most of ours), I don't think there's an appreciable difference between hatchling or setuptools.

[manics]

Does hatchling support editable installs (pip install -e . or the equivalent?)

[consideRatio]

@manics yepp!

[manics]

I agree it makes sense for new projects, and existing ones where there is a clear benefit. I'm sceptical of trying to change the build system for existing projects just to standardise things. It introduces a new barrier (learning a new build system) for existing contributors, and given how much the Python packaging ecosystem keeps changing I'm not convinced we can even commit to a chosen new system long term.