Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow separate control of the extension module name #2238

Closed
altendky opened this issue Sep 26, 2024 · 2 comments
Closed

allow separate control of the extension module name #2238

altendky opened this issue Sep 26, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@altendky
Copy link
Contributor

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.

@altendky altendky added the enhancement New feature or request label Sep 26, 2024
@messense
Copy link
Member

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.

@messense messense closed this as not planned Won't fix, can't repro, duplicate, stale Sep 26, 2024
@altendky
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants