Scaling PyO3 down with single-file Python extensions

[itamarst]

Scaling PyO3 down with single-file Python extensions

[itamarst]

As an alternative to the above syntax, the config part could be specified in setup.py as an argument to RustSingleFileExtension (or whatever it ends up being called) rather than in the Rust file.

[itamarst]

Some reasons this might be a bad idea:

1. Lack of reproducibility, if lock file support is not included. Adding lock file support increases scope.
2. Scaling up may become more complex since now you need to convert the current config to a Cargo.toml. This can likely be solved with tooling, but that's an increase in scope.
3. More likely to have errors (no syntax highlighting) and more difficult debugging of errors, in the Cargo.toml-equivalent config.

[adamreichold]

I think if one goes automatically generating a Cargo.lock, one could also implement this as automatically generating (or updating) a Cargo.toml file. The canonical path of src/lib.rs is only conventional IIRC and a Cargo.toml could change this to extension.rs.

[itamarst]

One alternative I just discovered to the proposal here is https://github.com/mityax/rustimport

I'll try playing around with it, and report what I've learned here.

[alex]

It seems to me that once the cargo-script RFC is stable, it'd be a much smaller amount of work to build this on top of that.

[itamarst]

So I played around with rustimport (https://pythonspeed.com/articles/easiest-rust-python/), and my feeling is it does quite well at simplifying prototyping. And there's maybe a use case for single-file Rust that is an extension you ship or distribute, but... it feels like prototyping is maybe the bigger use case.

So from my perspective it's probably not worth spending a lot of time on adding it to setuptools-rust, I'm happy to close this issue.

[itamarst]

Another alternative: https://www.maturin.rs/develop.html#import-hook