You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like the tests take about 12 minutes or so, but the CI workflow uses cargo-all-features, which checks all combinations of features. We currently have three of them, which means that the tests (probably) run 8 times.
Rust features are supposed to be additive. I realize this isn't always the case (e.g. the PROJ network feature might influence the results), but there's not that much place for strange interactions between them:
use-proj only re-exports some proj types AFAICT
proj-network only enables a proj feature; this could presumably influence some (doc-)tests though
serde only enables the serde integration
So I think it would be relatively safe to only run cargo check --no-default-features and cargo test --all-features, and maybe trim down the tests where proj-network could have an impact.
The text was updated successfully, but these errors were encountered:
I think that we probably don't have to test proj-network since any failure would occur and be evident upstream – we already test that enabling the network functionality changes the results in the proj crate, so barring a failure mode in which we accidentally deploy a proj crate version despite broken functionality and tests I think we can just use use-proj here?
I agree, testing with proj-network only introduces new failure modes for us: getting different results because of the extra grids and not working because of transient network issues.
It looks like the tests take about 12 minutes or so, but the CI workflow uses
cargo-all-features
, which checks all combinations of features. We currently have three of them, which means that the tests (probably) run 8 times.Rust features are supposed to be additive. I realize this isn't always the case (e.g. the PROJ
network
feature might influence the results), but there's not that much place for strange interactions between them:use-proj
only re-exports someproj
types AFAICTproj-network
only enables aproj
feature; this could presumably influence some (doc-)tests thoughserde
only enables theserde
integrationSo I think it would be relatively safe to only run
cargo check --no-default-features
andcargo test --all-features
, and maybe trim down the tests whereproj-network
could have an impact.The text was updated successfully, but these errors were encountered: