这是indexloc提供的服务,不要输入任何密码
Skip to content

Publish C dependencies and bindings as a separate library #3

@tmager

Description

@tmager

Core currently includes bindings for a small subset of the Arb C library. These are currently implemented by bundling a dynamically-linked library into the Core wheels and accessing its contents using ctypes. There are a couple of reasons that this isn't a good long-term solution:

  • It makes Core wheels extremely large -- 40+ MB for Linux wheels, though it's possible they could be slimmed down somewhat -- and slow to build the first time due to the lengthy C compilation step. This is inconvenient for:

    • Users: slow to download, multiple versions bloat pip cache
    • PyPI: we've already had to request additional storage for the Core project
    • Core contributors: the Arb bindings are rarely updated, and less-frequent contributors likely won't ever touch them, but the C library compilation still needs to happen as part of a local developer install

    Plus, we aren't actually getting any benefit from this: new versions of Arb are added relatively infrequently, so many versions of Core will ship with the same version of Arb.

  • Using ctypes this way isn't especially robust. We've already hit one bug that came about from it silently accepting the wrong number of arguments to a C function, and this approach also requires some kind of hacky platform-specific logic to actually locate the compiled library.

The solution to this first problem is relatively straightforward: split out the Arb bindings into a new package with a slower release cadence. We could do that without major changes and it would solve our immediate problems without significant risk of breaking anything.

The second problem is trickier. We could:

  • Do nothing, on the theory that the Arb bindings are a relatively small piece of the codebase and they change so infrequently that switching to another way of writing bindings would create more bugs than it would prevent.
  • Look at using Cython for the bindings. This should be more robust and better-supported, and might also have other benefits, but it's a fair amount of work.
  • Explore what other options are available for doing things like this.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions