WARNING: setup.py install is deprecated when using build

[stinovlas]

When I upgraded setuptools to 62.6.0, I get this warning:

* Creating virtualenv isolated environment...
WARNING setup.py install is deprecated. Use build and pip and other standards-based tools.
* Installing packages in isolated environment... (setuptools-grpc, setuptools>=62.4)
...

The funny thing is that I'm using python -m build while getting this error. I suppose that build probably calls setup.py install internally, but it's still weird to see this warning while using these standards-based tools.

What I'm actually worried about is this: We already use pyproject.toml to specify our build system and setup.cfg to package configuration. However, we also need some custom build steps in some of our packages. E.g. we have some packages with protocol buffers source files and we want to build python modules out of them when we build the package. For that reason, we have customized build command like this:

from setuptools import setup
from setuptools.command.build import build

class CustomBuild(build):
    # build_grpc command is provided in another package and hooked via distutils.command entry point
    sub_commands = [('build_grpc', None)] + build.sub_commands

setup(cmdclass={'build': CustomBuild})

We also have other custom build steps in other packages, not just gRPC. So, my question is: will this be supported even after setup.py install is removed? Does the deprecation also cover other commands such as setup.py build? And if so, how will we be able to customize our build after that happens?

Btw. I would very much appreciate to customize build sub commands in setup.cfg or pyproject.toml, but I haven't been able to make it work and documentation doesn't say anything about it, so I guess that's not currently possible?

[abravalheri]

Hi @stinovlas thank you very much for opening this discussion.

WARNING setup.py install is deprecated. Use build and pip and other standards-based tools.

If you already have a pyproject.toml with a build-backend = "setuptools.build_meta", I suspect that the warn happens because of an old version of virtualenv/venv being used to install setuptools (but I cannot be sure without seeing a reproduction)... Maybe updating the installations of build[virtualenv] and virtualenv in you environment would solve that?

is: will this be supported even after setup.py install is removed?

Yes, there is no currently plan to deprecate the existence of the setup.py file. What is actually deprecated is the usage of python setup.py as a CLI script. Setuptools will still read and process setup.py as part of the build. What changes is that setuptools no longer wants to maintain the command line interface provided by setup.py.

Does the deprecation also cover other commands such as setup.py build?

Yes, any usage of python setup.py is discouraged. For project management tasks (e.g. python setup.py test or python setup.py docs), users are encouraged to migrate to an actual task runner like tox/nox. If you have a packaging-related use case that you feel cannot be covered by build (and is not considered deprecated, e.g. building an .egg), please feel free to start a new discussion about a feature request.

how will we be able to customize our build after that happens?

The approach you shared (adding build steps via build sub-commands) is perfectly fine (and very well executed in my opinion - maybe your example is only missing adding build_grpc to the cmdclass?).

Btw. I would very much appreciate to customize build sub commands in setup.cfg or pyproject.toml, but I haven't been able to make it work and documentation doesn't say anything about it, so I guess that's not currently possible?

I think we, as a community, need to think about a good design to make this happen. There are a few discussions already going on about this (e.g. #2899), but I don't feel like we have consensus yet. Once we reach consensus on how we want the interface to look/work, we can go ahead and implement it.

Currently, there is a under-documented feature that allow some implementation of cmdclass to be set via setup.cfg: #2571. However not all implementations may work (that will depend on the import system behaviour, because setuptools.build_meta does not add "." to sys.path). However, as you can see by the discussion, this does not look like a definitive solution.

[stinovlas]

@abravalheri Thank you for a very comprehensive answer!

Maybe updating the installations of build[virtualenv] and virtualenv in you environment would solve that?

You're right. The warning disappeared after upgrading virtualenv.

how will we be able to customize our build after that happens?

The approach you shared (adding build steps via build sub-commands) is perfectly fine (and very well executed in my opinion - maybe your example is only missing adding build_grpc to the cmdclass?).

Is it required to specify build_grpc in cmdclass when it's exported as distutils.commands entry point in its own package like this?

[options.entry_points]
distutils.commands =
    build_grpc = setuptools_grpc.build_grpc:build_grpc

I think we, as a community, need to think about a good design to make this happen. There are a few discussions already going on about this (e.g. #2899), but I don't feel like we have consensus yet. Once we reach consensus on how we want the interface to look/work, we can go ahead and implement it.

Currently, there is a under-documented feature that allow some implementation of cmdclass to be set via setup.cfg: #2571. However not all implementations may work (that will depend on the import system behaviour, because setuptools.build_meta does not add "." to sys.path). However, as you can see by the discussion, this does not look like a definitive solution.

Thank you for the pointers. I'm looking forward to further development 🙂.

[abravalheri]

Hi @stinovlas,

Is it required to specify build_grpc in cmdclass when it's exported as distutils.commands entry point in its own package like this?

The thing with entry-points is that they are valid after you install your project, but not during build times. If you are creating a setuptools plugin, it is fine, but they might not take effect when you are building the project itself.

Depending on the way you configure setuptools you might have a *.egg-info directory inside of your sdist, and that would do the trick to make the entry-points available during build time (thanks to importlib-metadata, but this is very configuration-specific.

If you add them directly to cmdclass, you bypass this complication.

Thank you for the pointers. I'm looking forward to further development 🙂.

Please feel free to add your suggestions, it is a good thing if we can design this together with the community.