-
Notifications
You must be signed in to change notification settings - Fork 733
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
Replace extension-module feature with pyo3::main and pyo3::test #921
Conversation
@m-ou-se I'm not quite sure if this solves what you need for |
it might be a good idea to be able to apply |
Awesome, thank you!
|
another idea is to just merge them both into |
No, we only need this
I think it does make sense for
I quite like |
Also, I quite like having But maybe if we prefer just calling Let me know what design you all like best 😊 |
honestly, I'm fine with having |
I don't think an attribute like that is the way to go. Some of my projects use Python somewhere in some module, but not directly from It also requires the use of a procedural macro, making the recently introduced But even then, it seems not like a very ergonomic solution. Everybody who forgets this macro (including all existing code) will just get a long linker error with no proper explanation. :( Maybe this is something to be solved on the side of Cargo/Rustc instead. This is not the only problem when compiling plugins/extensions (whether for Python or other things). There's the problem of Maybe it's time to propose an addition to Cargo, allowing something like [[bin]]
crate-type = ["plugin"] and then letting build scripts specify flags for these separately. Or something in that direction. |
I agree that the error case for forgetting to link is not very ergonomic. A cargo plugin sounds great, though I guess it could be a long time before the design and implementation of it is complete. Maybe a better workaround for now is to keep |
@davidhewitt That might be the least surprising option for now. None of the solutions are perfect, but at least this one means that the regular use cases don't change, and the macro only needs to be used in the edge cases. |
558939e
to
b12549a
Compare
b12549a
to
2f8a725
Compare
Yikes, accidentally re-used the same branch name for a new PR... Closing this PR. I plan to revisit the linking macro, but otherwise I think this is dead code. |
This is an experiment to remove
extension-module
feature, with its known linking problems. See #904 #771 #341Instead, to enable linking to
libpython
when needed, I introduce two proc macro attributes#[pyo3::main]
and#[pyo3::test]
which force linking using the macro suggested in #771To sweeten the deal, both of these attributes can automatically acquire the GIL if you make the first argument
py: Python
. e.g.:This implementation is not yet complete - I hard-coded
libpython3.8
to test on my laptop. Needs to use proper detection of the python library. It also breaks windows where this hack isn't needed.I'm happy with
#[pyo3::main]
, though I wonder if adding this link arg to every#[pyo3::test]
is overkill - an alternative would be to have apyo3_test_link_python!()
macro or so which could be included once in each test file.