[issue35893] distutils fails to build extension on windows when it is a package.__init__

Steve Dower added the comment: Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils. If this issue does not relate to distutils, please remove the component and reopen it. If

[issue35893] distutils fails to build extension on windows when it is a package.__init__

Evandro Coan added the comment: It is missing the import on: #START from distutils.command import build_ext def get_export_symbols(self, ext): parts = ext.name.split(".") print('parts', parts) if parts[-1] == "__init__": initfunc_name = "PyInit_" + parts[-2] else:

[issue35893] distutils fails to build extension on windows when it is a package.__init__

Steve Dower added the comment: Agreed that it should go to setuptools in order to support third-party packages. In general, those of us who ever touch distutils these days (basically just me?) are only really maintaining those parts necessary to build Python and its own modules. Since this

[issue35893] distutils fails to build extension on windows when it is a package.__init__

Paul Ganssle added the comment: Well, there's some tentative plan for `setuptools` to completely adopt distutils, so in some sense all distutils bugs are setuptools bugs as well. That said, the reason to report it in setuptools as well is that setuptools still supports Python 2.7, 3.5 and

[issue35893] distutils fails to build extension on windows when it is a package.__init__

Ronald Oussoren added the comment: The bug is the stdlib, and I've checked that setuptools just calls the code in distutils in this case. IMHO it would be better to fix this in the stdlib. (Unselecting python 3.6 because that's in security-only mode by now) -- versions: -Python

[issue35893] distutils fails to build extension on windows when it is a package.__init__

Paul Ganssle added the comment: @Ronald Ah, interesting, I missed that. In my experience, distutils is pretty static and it's not particularly common to merge changes into it. Whether or not this is in scope for distutils, it's definitely in scope for setuptools - do you mind opening an

[issue35893] distutils fails to build extension on windows when it is a package.__init__

Ronald Oussoren added the comment: @Paul, modulegraph2 uses flit, but I do use setuptools to build extensions in the test suite. The problematic setup.py file is in testsuite/nodebuilder-tree. I do have a workaround in that setup.py: # START def get_export_symbols(self, ext): parts =

[issue35893] distutils fails to build extension on windows when it is a package.__init__

Paul Ganssle added the comment: @Ronald The module you've linked to seems to be using flit and doesn't have any C extensions. Did you change over the build process, or am I missing something? -- ___ Python tracker

[issue35893] distutils fails to build extension on windows when it is a package.__init__

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35893] distutils fails to build extension on windows when it is a package.__init__

Ronald Oussoren added the comment: FWIW the project in question is modulegraph2 , which almost works on Windows, except for this issue and some incorrect code on my side that assumes virtualenv on Windows behaves the same as on

[issue35893] distutils fails to build extension on windows when it is a package.__init__

New submission from Ronald Oussoren : Python supports having a C extension for the the __init__ of a package (instead of having __init__.py). This works fine on Linux, but on Windows distutils fails to build the C extension because it assumes the entry point is named PyInit___init__ while