You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before distutils was scheduled for removal, distutils.command.build.build used to be an ideal place to add custom build steps. The pattern usually looks something like this:
Typically, the custom behaviour can be put in a custom setuptools.Command but in order for that command to be ran automatically by pip wheel . or when installing from an sdist, the build command still needs to be monkeypatched
Describe the solution you'd like
I want some place in the setup process where I can prepend arbitrary build steps to be ran when building wheels or installing from sdists or git. In my case, I want to use this to invoke a C compile using a custom build system. Currently, when distutils disappears, I have no way for the platforms that can't use precompiled wheels to be able to install directly from an sdist on PyPI.
Alternative Solutions
I see that I can accomplish the same thing by overriding build_py instead. This feels like a hack though.
Perhaps a better solution would be the ability to mark custom commands as necessary prerequisite commands to the install or build commands. Setuptool's aliases feature looks tantalisingly close - using the following setup.cfg configuration I can replace build with a custom step + the original build.
[aliases]build = custom_step build
This does indeed correctly override python setup.py build but does not apply when other commands invoke build so that pip install . or installing from an sdist still calls the original, non-extended build. So either making the above config apply to implicitly called commands or adding some kind of [command-requires] build = custom_step option do the job.
Additional context
No response
Code of Conduct
I agree to follow the PSF Code of Conduct
The text was updated successfully, but these errors were encountered:
For now, you can continue to rely on distutils. Even as it goes away from the standard library, Setuptools is adopting it such that if you run with SETUPTOOLS_USE_DISTUTILS=local then import distutils resolves to Setuptools' bundled copy.
But I agree, long-term, there should be a better way to introduce build steps, which is captured in #2591.
What's the problem this feature will solve?
Before distutils was scheduled for removal,
distutils.command.build.build
used to be an ideal place to add custom build steps. The pattern usually looks something like this:Typically, the custom behaviour can be put in a custom
setuptools.Command
but in order for that command to be ran automatically bypip wheel .
or when installing from an sdist, thebuild
command still needs to be monkeypatchedDescribe the solution you'd like
I want some place in the setup process where I can prepend arbitrary build steps to be ran when building wheels or installing from sdists or git. In my case, I want to use this to invoke a C compile using a custom build system. Currently, when distutils disappears, I have no way for the platforms that can't use precompiled wheels to be able to install directly from an sdist on PyPI.
Alternative Solutions
I see that I can accomplish the same thing by overriding
build_py
instead. This feels like a hack though.Perhaps a better solution would be the ability to mark custom commands as necessary prerequisite commands to the
install
orbuild
commands. Setuptool's aliases feature looks tantalisingly close - using the followingsetup.cfg
configuration I can replacebuild
with a custom step + the original build.This does indeed correctly override
python setup.py build
but does not apply when other commands invokebuild
so thatpip install .
or installing from an sdist still calls the original, non-extendedbuild
. So either making the above config apply to implicitly called commands or adding some kind of[command-requires] build = custom_step
option do the job.Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: