pyproject-hooks: Don't pip install without user knowledge and allow to opt out

It seems like pep517.build and pep517.check will run pip install on their own without ever telling anything to the user, and there’s no way to disable this.

Linux distributions often need a tool that simply builds a wheel, one that does not go run things like pip install on our backs. A lot of the reasons have been outlined in https://github.com/pypa/setuptools/pull/2080. The problem is not just it is using pip, it’s that it is fetching sources from the internet and installing packages without I ever tell it to do it. When I make a distribution package I want to be the one fetching and verifying all sources, and I want to be in control of what is installed to the filesystem.

All I need is a simple build system without many dependencies (because we will need to bootstrap those, which is a lot of work). It should not do any package management, just build what I ask it to. It will fail if there are missing build dependencies.

And I believe this should be the default behavior, I think python -m pep517.* should be a build system first (actually, I think it should only be a build system but I don’t think you agree). If a user wants to install a project from source, pip works, but please let’s not add pip as a dependency at this level. If you really want pip to be run I would suggest adding a command-line option that would enable that behavior.

Right now python -m pep517.build will error out because pip is not installed:

/usr/bin/python: No module named pip
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 193, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.8/site-packages/pep517/build.py", line 124, in <module>
    main(parser.parse_args())
  File "/usr/lib/python3.8/site-packages/pep517/build.py", line 120, in main
    build(args.source_dir, dist, args.out_dir)
  File "/usr/lib/python3.8/site-packages/pep517/build.py", line 87, in build
    env.pip_install(system['requires'])
  File "/usr/lib/python3.8/site-packages/pep517/envbuild.py", line 100, in pip_install
    check_call(
  File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python', '-m', 'pip', 'install', '--ignore-installed', '--prefix', '/tmp/pep517-build-env-v568jxh0', 'flit_core >=2,<3']' returned non-zero exit status 1.

There is no reason for pip to be there if I have every build dependency already.

Just a note on the shape python packaging is taking. I believe everything here should be modular, having a build system and installer, and then a package manager. I think pip should offload the work to these tools and just deal it the package management (fetching sources, managing dependencies, etc.).

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 2
  • Comments: 16 (16 by maintainers)

Most upvoted comments

Maybe it was a mistake to make the high-level pep517.build and pep517.check interfaces at all. The focus of pep517 is an implementation of what the PEP 517 spec describes: running hooks in a subprocess, handling fallbacks when an optional hook isn’t implemented, and reporting certain likely problems as clear exceptions.

pep517.build implements essentially the simplest possible frontend tool, to exercise and illustrate how the core functionality can be used. Probably every serious frontend would write its own equivalent of that layer rather than using it from pep517.