Restore setup.cfg only packages?

[henryiii]

Pip 21.1.2 gained support for building legacy packages with just setup.cfg, which we lost in 0.4.0. The argument that convinced me of that breaking change was pip's lack of support for it - but now that's not true anymore. Should we restore support for setup.cfg only projects? I think it's a bad idea for pip to be able to pip wheel . a package but build cannot build it.

See #260, specifically #260 (comment), and pypa/pip#9945.

Edit: This has been corrected in pip, so build 0.4.0 is correct. :)

[henryiii]

(Of course, also happy if pip reverts to not building setup.cfg-only packages with no pyproject.toml, but either way they should match)

[pradyunsg]

pypa/pip#9547 is the relevant pip PR and discussion.

[henryiii]

The change didn't happen in pypa/pip#9547, though; that only added editable installs for setup.cfg - that was part of Pip 21.1.0 and 21.1.1. The change happened in pypa/pip#9945, and is only part of Pip 21.1.2.

[henryiii]

Note this has nothing to do with editable installs, just with the verification step. Pip used to check for pyproject.toml or setup.py, now it checks for setup.cfg too, which means a setup.cfg but no pyproject.toml or setup.py is now valid in pip. Before build 0.4.0, it was also valid in build. Build and pip should do the same thing.

It's all a "correctness" check, both tools are just fine with a setup.cfg only package if you remove the checks.

[layday]

Can someone explain why we'd want to allow this? You can't invoke setuptools without a setup.py, without PEP 517. Why would we add a mode of pyproject.toml-lessness which wasn't there before?

[uranusjr]

You can't invoke setuptools without a setup.py, without PEP 517.

Technically you can:

$ python -c 'from setuptools import setup; setup()' --help
Common commands: (see '--help-commands' for more)

  setup.py build      will build the package underneath 'build/'
  setup.py install    will install the package

Global options:
  --verbose (-v)      run verbosely (default)
  --quiet (-q)        run quietly (turns verbosity off)
  --dry-run (-n)      don't actually do anything
  --help (-h)         show detailed help message
  --no-user-cfg       ignore pydistutils.cfg in your home directory
  --command-packages  list of packages that provide distutils commands

Information display options (just display information, ignore any commands)
  --help-commands     list all available commands
  --name              print package name
  --version (-V)      print package version
  --fullname          print <package name>-<version>
  --author            print the author's name
  --author-email      print the author's email address
  --maintainer        print the maintainer's name
  --maintainer-email  print the maintainer's email address
  --contact           print the maintainer's name if known, else the author's
  --contact-email     print the maintainer's email address if known, else the
                      author's
  --url               print the URL for this package
  --license           print the license of the package
  --licence           alias for --license
  --description       print the package description
  --long-description  print the long package description
  --platforms         print the list of platforms
  --classifiers       print the list of classifiers
  --keywords          print the list of keywords
  --provides          print the list of packages/modules provided
  --requires          print the list of packages/modules required
  --obsoletes         print the list of packages/modules made obsolete

This is explicitly supported by setuptools and is (roughly) what pip is doing.

[layday]

You can, not have a module or script and use Python's -c option instead. You could also call your setup.py, teardown.py. As a matter of practicality you are going to do neither of those things because you would not expect tooling to work with arbitrary filenames or without a setup.py, and the latter did not work until pip 21.1.2. So, why would we add a mode of pyproject.toml-lessness which wasn't there before?

[uranusjr]

I don’t disagree with your reasoning; I don’t think build needs to allow that use case.

[FFY00]

The setuptools upstream has denied adding that as an entrypoints, so I don't think doing python -c is properly supported.

[henryiii]

Setuptools is trying to make setup.cfg only projects a valid replacement for setup.py projects. Pip has special support for setup.py only projects for historical reasons, and PEP 517 includes mentions of them. Pip now even has special support for setup.cfg-only projects and editable mode, to help with this as well.

From a practical standpoint, it's already hard to convince users to move from setup.py to setup.cfg, and hard to convince them to use pyproject.toml, and hard to convince them to use build instead of python setup.py sdist bdist_wheel that they've been doing for years. Making each one independent makes this easier - if you go from setup.py to setup.cfg only, then add pyproject.toml in a later step, that's is clearly an easier sell.

All the machinery already exists for this! Build < 0.4 supported it, pip supported it as soon as the check was loosened. The only think is a static check that was added to provide a better error message if someone targets the wrong directory when building. I think we should probably loosen the check - if someone points at a directory with just a setup.cfg, they clearly are pointing at a directory intended to be built.

Longer term, I think PEP 517 should be modified to say that "classic" builds have setup.py or setup.cfg present. However, on rereading it, it says "if pyproject.toml is present, either setup.py should be executed or setuptools.build_meta:__legacy__ should be executed - and that's what's supporting setup.cfg for pip and build. So this static check really should include anything supported by setuptools.build_meta:__legacy__, which is setup.py or setup.cfg currently - I don't think PEP 517 has to be modified.

[FFY00]

As per the reasoning I presented in pypa/pip#9945, I am gonna deny this.

[henryiii]

Seems reasonable. Maybe someone will make a PR to pip or propose an edit PEP 517 to make the setuptools.build_meta:__legacy__ call required instead of setup.py - that's unlikely, but maybe it will provide incentive to merge the PR to pip instead. :)

[FFY00]

The pip PR removing support for these projects was just merged a few minutes ago.

[henryiii]

That's awesome! Then I'm happy. :)

Xref: pypa/pip#10031