PyPolicyDefinition and related Verifier API changes

[deivse]

No description provided.

[deivse]

This is just the rust changes, I haven't adjusted the tests for the new API where things are accessible via .policy instead of directly, nor have I updated the .pyi files. I'll get to that tomorrow.

[deivse]

Buut, this is a good time to discuss if we do want these things to be accessible only via the policy field on the verifiers, or if we want to keep the old API alongside that for backwards-compatibility/convenience. Not sure about that to be honest.

[reaperhulk]

If they're just aliases then my opinion here is that we keep, but raise warnings and remove in 46. We have explicitly stated this isn't a stable API yet and is not subject to our backwards compatibility policy, but we do have consumers so we should give them a window for migration. @alex do you have an opinion?

[alex]

What @reaperhulk said sounds fine.

[deivse]

Any pointers on what to look at for implementing deprecation warnings for python getters in rust? I think I have seen something along these lines in the codebase but I have no idea where anymore. (Will update the PR tomorrow - it's already evening here in Prague)

[reaperhulk]

cryptography/src/rust/src/x509/crl.rs

Lines 262 to 264 in d860aaa

	let warning_cls = types::DEPRECATED_IN_42.get(py)?;
	let message = cstr_from_literal!("Properties that return a naïve datetime object have been deprecated. Please switch to next_update_utc.");
	pyo3::PyErr::warn(py, &warning_cls, message, 1)?;

should point you the right direction

[deivse]

Exactly what I was looking for, thank you! Will report back tomorrow.

[deivse]

I decided to rename PyPolicyDefinition to PyPolicy. The original name was to better reflect that it holds a PolicyDefinition, not a Policy, but I think I prefer to maintain the convention of PyXXX name directly corresponding to XXX in python.

PS: Will add the deprecated getters back in in a bit.

[alex]

Hmm, this should be unreachable from the Python API, right?

[alex]

If yes, this can just be a panic.

[deivse]

I think I came up with a cleaner and better solution in general - instead of adding a None value to SubjectOwner, I just made OwnedPolicyDefinition use Option<SubjectOwner> as the owner. This way the build_subject function doesn't need to handle None (.expect is used in the build_server_verifier method), and even the additional test shouldn't be needed.

[deivse]

Take a look and tell me if u prefer it that way. If not I can revert back to old behaviour with a panic instead of returning pyerror.