search

PyO3 / maturin

Build and publish crates with pyo3, cffi and uniffi bindings as well as rust binaries as python packages
https://maturin.rs
Apache License 2.0
3.99k stars 275 forks source link

allow separate control of the extension module name #2238

Closed altendky closed 2 months ago

altendky commented 2 months ago

Often, extension modules are given a leading _ to mark them as private and encourage use of the public wrapper pure python file/package/module. For example, you are expected to use the sqlite3 package which in turn imports the private _sqlite3 extension package.

$ python -c 'import sqlite3, _sqlite3; print(sqlite3); print(_sqlite3)'
<module 'sqlite3' from '/home/altendky/.pyenv/versions/3.12.4/lib/python3.12/sqlite3/__init__.py'>
<module '_sqlite3' from '/home/altendky/.pyenv/versions/3.12.4/lib/python3.12/lib-dynload/_sqlite3.cpython-312-x86_64-linux-gnu.so'>

I looked around and tried changing several names in various configs but did not find any separate control of the import package name vs. the extension module name.

Without having dug into the source, it seems like this might be as simple as a config entry to override the extension module name and code to apply that name to the extension module file writing when it is specified.

Let me know how you feel about this feature. If it sounds good, I could dig into the source and attempt a PR.

messense commented 2 months ago

See https://www.maturin.rs/project_layout#import-rust-as-a-submodule-of-your-project

I don't think we should support the use case like sqlite3 v.s. _sqlite3, it may make sense for standard library to do that, but for third party packages, putting the dylib inside the main package as submodule makes more sense.

altendky commented 2 months ago

Welp, it seems that this turned out to be a support request and not a feature request. I was not targeting exactly the _sqlite3 situation, it was just a simple example to reach for of having the extension module use a leading _. Your suggestion of the extension module being a member of the package was my actual target. Sorry.

Thank you for the doc link. I had looked in the configuration doc page and a few other places and tried using all the name fields I saw without success. But... I did not try an import path as shown in your submodule doc link. It does appear that it has worked as I hoped in my case.

Thank you for the quick support.