chrono-tz tests fail

[cjwatson]

Bug Description

I noticed as a result of Debian's automatic tests that the chrono-tz feature tests fail on current main (12a1792); see attached backtrace. I don't know much about this, but this looks a bit like what was fixed in #4790, although that was in a different conversions file.

Steps to Reproduce

cargo test --all-targets --no-default-features --features chrono-tz

Backtrace

error[E0599]: no method named `into_pyobject` found for struct `DateTime` in the current scope
   --> src/conversions/chrono_tz.rs:120:45
    |
120 |             let pydates = dates.map(|dt| dt.into_pyobject(py).unwrap());
    |                                             ^^^^^^^^^^^^^ method not found in `DateTime<Tz>`
    |
    = help: items from traits can only be used if the trait is implemented and in scope
note: `conversion::IntoPyObject` defines an item `into_pyobject`, perhaps you need to implement it
   --> src/conversion.rs:38:1
    |
38  | pub trait IntoPyObject<'py>: Sized {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Your operating system and version

Debian testing

Your Python version (python --version)

Python 3.13.6

Your Rust version (rustc --version)

rustc 1.86.0 (05f9846f8 2025-03-31) (built from a source tarball)

Your PyO3 version

main (post-0.25.0)

How did you install python? Did you use a virtualenv?

apt

Additional Info

No response

[cjwatson]

@plugwash's patch in https://salsa.debian.org/rust-team/debcargo-conf/-/blob/d8e6621c61e6e04e865e016f8c4b3079d07379b6/src/pyo3/debian/patches/fix-test-feature-requirements seems to fix this.

[alex]

I don't think that patch is correct, I think it's basically just skipping the test.

I think the real problem is that that test assumes the chrono feature is also used.

[davidhewitt]

Hmm for this and #5345 can you explain how the debian test system is working, is it running each feature in turn to test them in isolation?

In CI we only test them alone or in "full" mode to keep things simple, as all the features themselves should be orthogonal. I can see an argument that we should test each feature in isolation in at least one CI run, however 🤔.

It's generally quite handy to rely on other features for the testing (as observed in both these cases). I am somewhat tempted to agree that skipping the test is ok; we have quite a few tests that depend on the macros feature, for example.

[alex]

I think macros is a red herring, if you want it to rely on anything its the chrono feature.

[cjwatson]

Yeah, by default we test each feature in isolation, but it's just a default. We can and do override this for specific packages in various ways, depending on what seems to make sense.

[plugwash]

can you explain how the debian test system is working, is it running each feature in turn to test them in isolation?

debcargo's standard test configurations are to test each feature in isolation, as well as default features and all features. We can disable individual test configurations but we can't easilly add new ones, which is a bit annoying sometimes.

I think macros is a red herring

I determined which features were needed by starting with a long list of features, and removing features until the tests failed. At least some of the tests in ordered_float.rs do seem to need the macros feature (I didn't go to the trouble of determining exactly which ones)