minrk
commented
1 year ago 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
consideRatio
In https://github.com/jupyterhub/kubespawner/pull/666 I transitioned kubespawner to no longer use setup.py but instead rely entirely on pyproject.toml together with PyPA's
hatchlingbuild 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.