Hi Scott, Thank you for the quick reply! Scott Kitterman <debian@kitterman.com> writes: > On Thursday, June 4, 2020 7:39:59 PM EDT Nicholas D Steeves wrote: >> Scott Kitterman <debian@kitterman.com> writes: >> > On Monday, April 13, 2020 5:18:53 AM EDT Dmitry Shachnev wrote: >> >> Hi Scott! >> >> >> >> On Sun, Apr 12, 2020 at 06:31:57PM -0400, Scott Kitterman wrote: >> >> > This being roughly the mid-point in the development cycle, I thought it >> >> > might be good to see where we are in terms of future Python packaging >> >> > developments. >> >> > >> >> > As I understand it, PEP-517 and PEP-518 are 'the future'. >> >> While importing the latest release of Fissix (a grammar parser used by >> Bowler) I found that it had a pyproject.toml but no setup.py. >> >> >> > I took a look at the presence of pyproject.toml files in the Debian >> >> > archive. There are currently 99 packages. Of those, only 28 specify a >> >> > 'build-backend', which is required by 517/518 to be useful for building >> >> > a >> >> > package. >> >> > >> >> > 25 specify: build-backend = "setuptools.build_meta" (including >> >> > setuptools) >> >> > 3 specify: build-backend = "flit_core.buildapi" (including flit) >> >> >> >> pyqt5 and pyqt5webengine specify: build-backend = "sipbuild.api". >> >> Is there existing documentation around if/how build-backend can be used >> to work around the absence of setup.py? >> >> > So they do. They didn't show up in my codesearch.d.n results, that makes >> > me wonder what else I missed. If anyone has an idea of a better way to >> > track this, please speak up. >> > >> >> > If build-backend is not specified, the build system has to fall back to >> >> > setup.py. >> >> > >> >> > I've recently package flit (just arrived in Testing) and written a flit >> >> > plugin for pybuild that's pending review for merging[1]. I also >> >> > packaged >> >> > pep517 for our pip package, so that's available to support future >> >> > Debian >> >> > tool development in this area. >> > >> > P1otr merged the flit plugin a little while ago, so it'll be in the next >> > dh- python upload. >> >> I think this is probably what is needed to unblock work on fissix (and >> thus Bowler), because its Makefile has: >> >> python -m pip install -r requirements.txt >> python -m pip install -r requirements-dev.txt >> python -m flit install --symlink >> >> [snip] >> >> Any advise for existing workarounds would be appreciated. So far the >> only idea I've had is writing or generating a setup.py, and then adding >> it as a quilt patch. > > That is probably the best approach for now. > Thank you for the ACK :-) > Ultimately we have two choices: > > 1. Add per-backend capability into pybuild as I have done with flit. > Depending on how many of them there are, this may or may not be a reasonable > approach. > > 2. Use the pep517 module with pip in our package build system. I think > Fedora has gone this direction. > > I prefer #1 because we want to produce a traditional bdist, not wheels, but > we'll have to do the work. I don't think we want an impenetrable morass of > zip files in /usr/lib/python3/dist-packages. > I also prefer #1. Here's an idea for reducing the work, and more importantly reducing the Debian-specific investment in time: Dephell (from the author of Poetry?) claims to support: egginfo, sdist, wheel, pip, piplock, pipfile, pipfilelock, poetry, poetrylock, already installed system-wide packages, plus setup.py, flit, conda, and pyproject. More interestingly it claims to be able to convert between formats, eg: dephell deps convert --from=pyproject.toml --to=setup.py Within a Debian packaging context this seems like it would be useful, because packages whose upstreams change formats could continue to use their existing rules file with the addition of a 'dephell deps convert' step. It seems like it might fit well with DPMT Policy, in that we could recommend conversion to a particular format, for use with a particular buildsystem, for uniformity of packaging. Finally, if that conversion capability works well then an effect is that Debian packaging is effectively decoupled from upstream buildsystem changes, and this seems like a good thing. Downside: Their installation instructions (curl -L dephell.org/install | python3) make me wonder if there is a fundamental cultural difference that would make this a no-go. tldr: Could integrating Dephell into dh_python solve these challenges once and for all? Regards, Nicholas
Attachment:
signature.asc
Description: PGP signature