Add a License

[sno2]

Hello, do you think you could add a license because I want to use your proc macro for inserting #[pyo3(get)] into all class fields? I also need to hide the attribute under a feature by default and the bug is a big blocker. Thanks

[mejrs]

I am willing to do that (I should have done it long ago), but I do not think you should use it.

It relies on #[cfg_eval] to expand eagerly:

• This requires you to use a nightly toolchain.
• The Rust team seems unlikely to stabilize it in its current form, if at all. See https://github.com/rust-lang/rust/pull/87221#issuecomment-914509921 for more about that (I think I agree with that statement).

While I personally use nightly features freely as this is a toy project and I don't mind it breaking on me, this is a pretty unstable feature. Certainly not something you should be using in production.

To resolve your issue now, you can also define some getters and gate those behind a cfg. Something like this:

#[cfg(feature = "pyo3")]
#[pymethods]
impl LocationConfig {
    #[getter]
    fn id(&self) -> PyResult<u32> {
        Ok(self.id)
    }

    #[getter]
    fn name(&self) -> PyResult<Option<String>> {
        Ok(self.name.clone())
    }

    // etc..
}

[mejrs]

Done.

[sno2]

I am willing to do that (I should have done it long ago), but I do not think you should use it.

It relies on #[cfg_eval] to expand eagerly:

• This requires you to use a nightly toolchain.
• The Rust team seems unlikely to stabilize it in its current form, if at all. See Stabilize built-in attribute macro #[cfg_eval] rust-lang/rust#87221 (comment) for more about that (I think I agree with that statement).

While I personally use nightly features freely as this is a toy project and I don't mind it breaking on me, this is a pretty unstable feature. Certainly not something you should be using in production.

To resolve your issue now, you can also define some getters and gate those behind a cfg. Something like this:

#[cfg(feature = "pyo3")]
#[pymethods]
impl LocationConfig {
    #[getter]
    fn id(&self) -> PyResult<u32> {
        Ok(self.id)
    }

    #[getter]
    fn name(&self) -> PyResult<Option<String>> {
        Ok(self.name.clone())
    }

    // etc..
}

Thanks for the feedback and adding the license, I hadn't realized that your solution still relied on nightly. I think I'll just still with dicts for my response data in Python for now and hope for #[pyclass(dataclass)] or something of sort.

[mejrs]

Something like a #[pyclass(get_all)] and #[pyclass(set_all)] is something I'd like too.