Support for custom build steps #2591
Comments
|
In demo-custom, I've created a project that relies on a custom-build command without any overriding of build or install commands. This approach required the explicit addition of the command in the setup.py for demo-custom. But it does demo the concept: Note |
|
This functionality would be useful for building the Gramps software. We have additional build steps for translations and manual pages. |
|
Thank you, @jaraco , for providing an example of this functionality. I was struggling to implement a custom build step for PyInstaller using Your approach as shown here is much cleaner and actually works. Looking forward to the finalized API. |
As described in pypa#2591, users might wish to add custom steps to the build process, and this can be done via sub-commands. The changes implemented here expose a new set of entry-points to facilitate this process. This allows the implementation of custom steps in 3rd-party plugins.
This approach was first proposed and discussed in pypa/setuptools#2591
As described in pypa#2591, users might wish to add custom steps to the build process, and this can be done via sub-commands. The changes implemented here expose a new set of entry-points to facilitate this process. This allows the implementation of custom steps in 3rd-party plugins.
I think we can get around requiring the users to explicitly add the sub-command, by changing the plugin to use I did created a proof of concept in https://github.com/abravalheri/experiment-setuptools-plugin. @jaraco what do you think of this approach? I think in the long term we will want to go for a different entry-point, however, this solution seems to be usable nowadays without any extra change. |
The comment in pypa/setuptools#2591 (comment) reports that users wanting to use the custom-command plugin need to explicitly add it using `setup.py`. This commit tried to demonstrate how that can be done without requiring the user to change their `setup.py`. The "installation" of the new sub-command is done via the `finalize_distribution_options` hook.
As described in pypa#2591, users might wish to add custom steps to the build process, and this can be done via sub-commands. The changes implemented here expose a new set of entry-points to facilitate this process. This allows the implementation of custom steps in 3rd-party plugins.
As described in pypa#2591, users might wish to add custom steps to the build process, and this can be done via sub-commands. The changes implemented here expose a new set of entry-points to facilitate this process. This allows the implementation of custom steps in 3rd-party plugins.
|
With Python 3.12 on our doorstep, I am searching right now for recommended ways to replace (#2928) from distutils.command.build import build
from distutils.command.clean import cleanfor steps such as class CopyPreBuild(build):
def initialize_options(self):
build.initialize_options(self)
# We just overwrite this because the default "build" (and "build/lib")
# clashes with directories many developers have in their source trees;
# this can create confusing results with "pip install .", which clones
# the whole source tree by default
self.build_base = "_tmppythonbuild"
def run(self):
# remove existing build directory
c = clean(self.distribution)
# ...I do not understand the example above to replace these with setuptools, as the migration guide suggests Since #2928 is closed, what is the current recommended practice to migrate such logic? :) |
|
Hi @ax3l , if you are using the latest versions of setuptools the existing code should still keep working even on Python 3.12. You can use |
I've seen cases where users wish to add custom steps to the build process (example, example). Historically, users have managed to work around the issue by overriding the
buildorinstallcommands (usingcmdclass), but this approach requires replacing the default command just to inject some behavior. Preferable would be to avoid having to override the default behavior and for Setuptools to present a protocol for extending build steps.And indeed, distutils already provides a mechanism to extend build steps through sub_commands.
My proposal is that the
buildcommand present an interface to append or prepend commands to the build subcommands such that a third-party provider could provide an independent command, expose it throughdistutils.commands, and either implicitly as part of the import or explicitly by the end user, append or prepend that command to the subcommands.I think it should be possible to demonstrate this behavior today just by mutating the sub_commands list directly, though I'd probably recommend a proper API for users to use.
The text was updated successfully, but these errors were encountered: