使用 distutils 分发预编译的 python 扩展模块

发布于 2024-08-25 07:06:43 字数 343 浏览 9 评论 0原文

今天快速介绍一下:我正在学习 Python distutils 库的详细信息,并且我想在我的包中包含一个 python 扩展模块 (.pyd)。我当然知道推荐的方法是在创建包时让 distutils 编译扩展,但这是一个相当复杂的扩展,跨越许多源文件并引用多个外部库,因此需要进行一些重要的操作才能获得所有内容工作正常。

与此同时,我有一个来自 Visual Studio 的已知扩展工作版本,并且希望在安装程序中使用它作为临时解决方案,以便我能够专注于其他问题。但是,我无法将其指定为模块,因为它们显然必须具有显式的 .py 扩展名。我如何在 setup.py 中表明我想要包含预编译的扩展模块?

(Python 3.1,如果重要的话)

Quick one today: I'm learning the in's and out's of Pythons distutils library, and I would like to include a python extension module (.pyd) with my package. I know of course that the recommended way is to have distutils compile the extension at the time the package is created, but this is a fairly complex extension spanning many source files and referencing several external libs so it's going to take some significant playing to get everything working right.

In the meantime I have a known working build of the extension coming out of Visual Studio, and would like to use it in the installer as a temporary solution to allow me to focus on other issues. I can't specify it as a module, however, since those apparently must have an explicit .py extension. How could I indicate in my setup.py that I want to include a pre-compiled extension module?

(Python 3.1, if it matters)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

吹泡泡o 2024-09-01 07:06:43

我通过重写 Extension.build_extension 解决了这个问题:

setup_args = { ... }
if platform.system() == 'Windows':
    class my_build_ext(build_ext):
        def build_extension(self, ext):
            ''' Copies the already-compiled pyd
            '''
            import shutil
            import os.path
            try:
                os.makedirs(os.path.dirname(self.get_ext_fullpath(ext.name)))
            except WindowsError, e:
                if e.winerror != 183: # already exists
                    raise


            shutil.copyfile(os.path.join(this_dir, r'..\..\bin\Python%d%d\my.pyd' % sys.version_info[0:2]), self.get_ext_fullpath(ext.name))

    setup_args['cmdclass'] = {'build_ext': my_build_ext }

setup(**setup_args)

I solved this by overriding Extension.build_extension:

setup_args = { ... }
if platform.system() == 'Windows':
    class my_build_ext(build_ext):
        def build_extension(self, ext):
            ''' Copies the already-compiled pyd
            '''
            import shutil
            import os.path
            try:
                os.makedirs(os.path.dirname(self.get_ext_fullpath(ext.name)))
            except WindowsError, e:
                if e.winerror != 183: # already exists
                    raise


            shutil.copyfile(os.path.join(this_dir, r'..\..\bin\Python%d%d\my.pyd' % sys.version_info[0:2]), self.get_ext_fullpath(ext.name))

    setup_args['cmdclass'] = {'build_ext': my_build_ext }

setup(**setup_args)
dawn曙光 2024-09-01 07:06:43

我在 Visual Studio 2017 中使用 Python 3.7、CMake 3.15.3 和 Swig 4.0.1 构建扩展库时遇到了同样的问题。构建系统生成三个文件:mymodule.py、_mymodule.lib 和 _mymodule.pyd。经过一系列的试验和错误,我发现以下组合可以工作:

  1. 创建一个“setup.cfg”文件,指定您正在安装一个包;例如:
    [metadata]
    name = mymodule
    version = 1.0

    [options]
    include_package_data = True
    package_dir=
        =src
    packages=mymodule
    python_requires '>=3.7'

    [options.package_data]
    * = *.pyd
  1. 更改 CMake 以创建分发目录结构,如下所示:
    setup.py
    setup.cfg
    src/
        mymodule/
                 __init__.py
                 _mymodule.pyd
  1. “setup.py”文件就很简单:
    setup()

这需要让 CMake 将“mymodule.py”输出文件重命名为“init.py” 。我使用 CMake 中的“安装”命令完成了此操作:


    install (TARGETS ${SWIG_MODULE_${PROJECT_NAME}_REAL_NAME} DESTINATION "${CMAKE_BINARY_DIR}/dist/src/${PROJECT_NAME}")
    install (FILES 
            setup.py
            setup.cfg
            DESTINATION "${CMAKE_BINARY_DIR}/dist"
    )

    install (FILES
            ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.py
            DESTINATION "${CMAKE_BINARY_DIR}/dist/src/${PROJECT_NAME}"
            RENAME "__init__.py"

我相信完成这项工作的关键秘密是将构建输出重新构建为 Python 包,而不是尝试让安装程序使用默认构建输出作为 Python 脚本。

I ran into this same issue while building an extension library using Python 3.7, CMake 3.15.3 and Swig 4.0.1 with Visual Studio 2017. The build system generates three files: mymodule.py, _mymodule.lib and _mymodule.pyd. After a bunch of trial and error, I found the following combination to work:

  1. Create a 'setup.cfg' file that specifies that you are installing a package; e.g:
    [metadata]
    name = mymodule
    version = 1.0

    [options]
    include_package_data = True
    package_dir=
        =src
    packages=mymodule
    python_requires '>=3.7'

    [options.package_data]
    * = *.pyd
  1. Change CMake to create a distribution directory structure as follows:
    setup.py
    setup.cfg
    src/
        mymodule/
                 __init__.py
                 _mymodule.pyd
  1. The 'setup.py' file is then trivial:
    setup()

This requires having CMake rename the 'mymodule.py' output file to 'init.py'. I did this with the 'install' command in CMake:


    install (TARGETS ${SWIG_MODULE_${PROJECT_NAME}_REAL_NAME} DESTINATION "${CMAKE_BINARY_DIR}/dist/src/${PROJECT_NAME}")
    install (FILES 
            setup.py
            setup.cfg
            DESTINATION "${CMAKE_BINARY_DIR}/dist"
    )

    install (FILES
            ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.py
            DESTINATION "${CMAKE_BINARY_DIR}/dist/src/${PROJECT_NAME}"
            RENAME "__init__.py"

I believe that the key secret to having this work was to restructure the build output as a Python package rather than trying to have setup use the default build output of as a Python script.

演出会有结束 2024-09-01 07:06:43

我有同样的问题。这对我来说是有效的。
我更改了模块的名称,只是为了一个简单的例子。

我的设置是:
Visual Studio 2017 项目构建了一个最终文件名为 myextension.pyd 的扩展,

然后我使用 mypy 模块中的 Stubgen 在本地创建了该模块的存根。

这是我的文件树

myextension/__init__.pyi
myextension/submodule.pyi
setup.py
myextension.pyd

这是 setup.py 的内容

from setuptools import setup, Distribution


class BinaryDistribution(Distribution):
    def has_ext_modules(foo):
        return True


setup(
    name='myextension',
    version='1.0.0',
    description='myextension Wrapper',
    packages=['', 'myextension'],
    package_data={
        'myextension': ['*.pyi'],
        '': ['myextension.pyd'],
    },
    distclass=BinaryDistribution
)

运行 pipwheel 后。 我得到了一个非常漂亮的轮子,其中包含扩展以及所需的存根。

I had the same issue. This is what has worked out for me.
I have changed the name of the module, just for the sake of a simple example.

My setup is:
Visual Studio 2017 Project which builds an extension with a final file name myextension.pyd

I then locally created the stubs for this module using stubgen from mypy module.

This is my file tree

myextension/__init__.pyi
myextension/submodule.pyi
setup.py
myextension.pyd

And this is the contents of setup.py

from setuptools import setup, Distribution


class BinaryDistribution(Distribution):
    def has_ext_modules(foo):
        return True


setup(
    name='myextension',
    version='1.0.0',
    description='myextension Wrapper',
    packages=['', 'myextension'],
    package_data={
        'myextension': ['*.pyi'],
        '': ['myextension.pyd'],
    },
    distclass=BinaryDistribution
)

After running pip wheel . I get a pretty nice wheel containing the extensions, along with the required stubs.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文