How to create both a c extension and a pure python package

Thomas Jollans tjol at tjol.eu
Wed Mar 10 16:45:50 EST 2021


On 10/03/2021 20:57, Mats Wichmann wrote:
> On 3/10/21 11:56 AM, Thomas Jollans wrote:
>> On 10/03/2021 18:42, Marco Sulla wrote:
>>> On Wed, 10 Mar 2021 at 16:45, Thomas Jollans <tjol at tjol.eu> wrote:
>>>> Why are you doing this?
>>>>
>>>> If all you want is for it to be possible to install the package from
>>>> source on a system that can't use the C part, you could just declare
>>>> your extension modules optional
>>> Because I want to provide (at least) two wheels: a wheel for linux
>>> users with the C extension compiled and a generic wheel in pure python
>>> as a fallback for any other architecture.
>>
>> What's wrong with sdist as a fallback rather than a wheel?
>>
>> That has the added benefit of people on other architectures have the 
>> opportunity to use the extension module if they have a compiler and 
>> the necessary libraries and headers installed...
>
> Doesn't that mean nasty failures for those don't have the correct 
> build setup (like almost every Windows user on the planet)?   This 
> isn't a snide question, I'm actually interested in solving roughly the 
> same problem as the OP.

I believe that this is pretty much exactly the problem that the 
"optional" flag for extensions solves.

docs: "specifies that a build failure in the extension should not abort 
the build process, but simply skip the extension."

I would assume this refers to *any* build failure (including a missing 
compiler), so people without a proper build system might get error 
messages, but should still get a working package (assuming of course the 
C extensions is *actually* optional, like an accelerator module).

But I don't have experience with this myself so take what I say with a 
grain of salt.


- Thomas





More information about the Python-list mailing list