Transition to pure PyProject.toml

Discussion about transitioning to pure Pyproject.toml using either setuptools or poetry.

@PhilipVinc Probably a question for another issue, but any chance you guys might consider using a python-poetry based toolchain to manage pyproject.toml? Makes life a bit easier re: dev dependencies, environments, and deployment.

I have a branch to transit plum to a pure setuptools + pyproject.toml (so not poetry) but was waiting for pip to get together and support editable installs. It seems they fixed it a few months ago so might as well open the PR.

This is now much easier to do since plum does no longer use cython.

If you think poetry > setuptools I’d be happy to know what’s the advantage for packaging @tbsexton ?

[wesselb]

@tbsexton, I would imagine that fully supporting both a Poetry-supported and non-Poetry dev. workflow might come with a fair amount of overhead.

I guess I was imagining some kind of halfway-house, where you don’t entirely exclude non-Poetry users. E.g., with a workaround to install dev. dependencies without Poetry and the ability to run test without Poetry, someone would be able to put together a PR on their own. This PR would fail CI/CD tests, as you point out, but at that point we could suggest they use Poetry to fix CI/CD and help them in doing so. Not entirely sure about this option. Just brainstorming all possibilites! @PhilipVinc, would you be happy with something along these lines, or would you prefer that development be possible entirely without Poetry too?

[tbsexton]

@PhilipVinc all awesome points.

I definitely agree w.r.t. v1.2 being new, and I actually didn’t know about generic “groups” until yesterday! 😅 Dev-dependencies have been around since the … beginning? … of poetry, and iirc the “groups” idea just expands on that tooling to make it generalize. I would recommend only using the e.g. poetry add -D sphinx syntax since all poetry users would be able to use that (w/o updating, I believe). Updating does have other benefits for our quality-of-life, like the new(ish) plugin system that lets us use Tiangolo’s (of FastAPI fame) poetry-version-plugin to manage version specification via, say, only the git tag.

@wesselb I guess the key question boils down to some things we could test out amongst ourselves in a new branch or two:

• does requiring use of poetry by developers add significant overhead (preventing contribution) that outweighs the quality-of-life improvements poetry provides?
• will the effort of supporting both poetry and non-poetry development workflows reduce overhead (encouraging contribution) enough to outweigh your overhead in continuing to support both workflows (e.g. people submitting pull requests that don’t validate dependencies through, say, poetry.lock, which could fail your ci/cd tests and have no non-poetry solution? just brainstorming here).