When cargo building pyo3 projects auto-add in the extension-module feature please

[gilescope]

At the moment maturin warns if a pyo3 project is built without the extension-module feature.

We can already do:

maturin develop --cargo-extra-args="--features pyo3/extension-module"

Why not add that flag in automatically if it's clear that it's not there? Having pyo3/extension-module turned on as a default feature seems like a footgun as people will just run cargo test and expect stuff to work on cli, IDEs etc. but will run into linking problems if they don't use --no-default-features. It's both unergonomic and confusing as the linker errors give no clue that you should have disabled a feature so it's tough on new users.

It would be great if maturin just by default did the right thing :-) -
(it could still squark that it wasn't found so adding it in explicitly.)

thoughs?

[davidhewitt]

I think that's a very good idea!

[konstin]

Blocked on PyO3/pyo3#1040 being resolved.

[messense]

After #605 lands, you can add the cargo-extra-args = "--features pyo3/extension-module" to the [tool.maturin] section in pyproject.toml and maturin will pick it up automatically.

Edit: if you are using maturin 0.13.0 and later, --cargo-extra-args was removed, add the following to pyproject.toml instead.

[tool.maturin]
features = ["pyo3/extension-module"]

[konstin]

I believe [tool.maturin] features is the way to go

[jmhodges]

Reading between the lines here, I think this issue closing means we could take an update to getting_started.md's examples and maybe to the FAQ to allow folks to run cargo test work out of the box

I'm willing to do that, would like to confirm what's desired.

I think what we want is the example pyproject.toml to gain a

[tool.maturin]
features = ["pyo3/extension-module"]

while the example Cargo.toml's dependencies looks like:

[dependencies]
pyo3 = "0.18.0"

(Or I could be convinced to make that pyo3 = { version = "0.18", features = ["anyhow"] } since that's so handy)

[jmhodges]

I could also be convinced that the recommended set up would be better as the mixed Python and Rust code per the maturin guide. I could be convinced since being able to write Python tests out of the box make it easier to ensure the Python API is ergonomic, while allowing cargo test and other cargo tools to work is useful for IDEs and rust analysis tools.

[messense]

I could also be convinced that the recommended set up would be better as the mixed Python and Rust code

You can generate a mixed Python/Rust project with maturin new --mixed.

[messense]

Reading between the lines here, I think this issue closing means we could take an update to getting_started.md's examples and maybe to the FAQ to allow folks to run cargo test work out of the box

Pull requests are welcome, I think we can also update the maturin new/init template:

maturin/src/templates/Cargo.toml.j2

Lines 14 to 15 in 46f4b1a

	{% if bindings == "pyo3" -%}
	pyo3 = { version = "0.18.0", features = ["extension-module"] }