On Fri, Mar 26, 2021 at 07:32:47PM -0400, Sergio Durigan Junior wrote: > Control: severity -1 serious > Control: tags -1 + help > > On Sunday, January 17 2021, Martina Ferrari wrote: > > > On 17/01/2021 01:06, Sergio Durigan Junior wrote: > > > >> Thanks for the bug report, Martina. > >> Yeah, this is strange. I don't think it should require pip, and > >> after > >> installing python3-pip here and re-running /usr/bin/pyproject-build I > >> noticed that it (obviously) invokes pip and downloads several things, > >> which IMO is a no-no. > > > > Yeah, that's bad. > > > >> The reason I packaged python3-build is because check-manifest started > >> depending on it. I'm thinking about removing the > >> /usr/bin/pyproject-build program and just shipping the library. Do you > >> think it could work? (Sorry, I'm not a PEP-517 expert). > > > > Honestly, I don't know much about it either.. I'd suggest discussing > > it with the python-modules team? I guess somebody there would know > > what to do. > > I'm marking this bug as serious because I don't think we want a clearly > broken package in bullseye. > > I don't have much time to work on it right now, so I'm tagging this bug > as "help" and would appreciate if someone could take another look and > check if it's possible to fix it, or if it even makes sense having this > package in Debian, given that python-build seems to depend on > downloading things via pip and all... > > The only reverse-dependency of python3-build is check-manifest, which is > another package I've uploaded, and nothing really depends on it, so I'm > fine if nobody steps up to fix this bug and both packages are excluded > from bullseye.
Hm. I may be a bit off-base here, but I needed to look at the "build" tool a while ago as part of $REAL_JOB, and, hm... ...is this not how python3-build is supposed to operate? From what I know (which may not be completely correct), it has two basic operating modes: - isolated (the default one): create a virtual environment, make sure that the specified build system's dependencies are satisfied in there, then run the specified build system's PEP 517 hook for creating wheel packages - non-isolated (the -n command-line option): do not create a virtual environment, assume that the build system itself and all its dependencies are already installed in the environment of the Python interpreter that "build" is being run with, so just invoke the build system's PEP 517 hook for creating wheel packages So if one invokes `python3 -m build --wheel` (which is the default target if none are specified), "build" will create a virtual environment, then look at the pyproject.toml file and figure out what packages need to be installed within the newly-created environment. After that, it will use pip to install them. The way to avoid that is to use build's non-isolated mode by specifying the -n option on the command line. Of course, this brings along all the perils of a non-isolated build, e.g. not noticing forgotten build dependencies that are accidentally present in the current environment. So... I think that this is the way the "build" tool is supposed to operate. If somebody needs to use it with assuredly nothing downloaded from external sites, e.g. during a Debian package build, then I think a non-isolated build is the way to go. I hope this was useful in some way - I thought I'd make things a bit clearer for people who are not familiar with the tool itself. If somebody still decides that the "build" tool's default mode of operation makes it unsuitable for Debian, well, I guess that would be a valid viewpoint, but IMHO that would also apply to many, many other Debian packages related to various language ecosystems that have "download stuff from a central repository" as their main purpose :) Thanks, everyone, for your work on Debian! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
