Decouple proj and proj-sys tests

[urschrei]

Once again, the fact that we run the same test suite for proj and proj-sys is causing problems: #230 can't be merged because it requires the proj tests to pass, but that's blocked on #228, which is blocked on #230, so we now have to decide whether we want to manually merge #230 and push a release. Is there some sensible way of doing this?

[lnicola]

I'm probably missing something, but why is #228 blocked on #230?

[urschrei]

#228 is failing because of the flate2 version issue that was fixed in #229. I suppose I could backport the fix to a proj-sys v0.25.1 release and use that to merge #228.

[lnicola]

And why can't we bump the proj-sys dependency in the manifest in #230?

#228 is failing because of the flate2 version issue

Hmm, I don't see any CI there.

[urschrei]

And why can't we bump the proj-sys dependency in the manifest in #230?

…and merge #228 after that, but before releasing the new proj version? We could…

#228 had failing CI yesterday, I assume there's some github problem somewhere.

[urschrei]

I'm really confused now. It passed last time: https://github.com/georust/proj/actions/runs/14513724387

I'm gonna try to merge it and then see where we are.

[lnicola]

#228 is failing because of the flate2 version issue that was fixed in #229

Okay, so why can't we merge it right now, even before #230? We take a path dependency on proj-sys, so whether it's on crates.io makes no difference.

[urschrei]

Yeah true. It just means that proj wouldn't be publishable before the new proj-sys was published, right? Even if you have a path dependency, you can still get a version mismatch if your dep is on 0.25.0 but you ask for 0.26.0.

Anyway seeing as how the CI on #228 was passing but not being reported, I bypassed the merge queue and now #230 is a PR (with passing CI) for new releases of both crates.

In any case it's still annoying to have proj-sys CI gated on proj tests passing.

[lnicola]

In any case it's still annoying to have proj-sys CI gated on proj tests passing.

I think it makes sense, what if we inadvertently break the most important consumer (proj)?

[urschrei]

It's a sys crate with its own tests, so if a consumer breaks then the consumer is the "problem"?