This repo's circlular dependency makes it hard to make breaking changes

[nyurik]

The geo crate in this repo depends on the proj crate that lives in a separate georust/proj repository. proj crate depends on the geo-types crate from this repo. This makes it impossible to make breaking changes to the geo-types because CI would not compile the geo crate because proj needs to be updated first. Update: The wkt lib has exactly the same problem: geo uses jts-test-runner which uses an older wkt 0.9.1 which uses geo-types

I think we should either bring proj into this repo, or separate geo-types into a separate repo.

Merge proj into this repo

PROs:

• simpler to make cross-crate breaking changes
• CI ensures consistency
• easy to rollback if needed
• simpler path towards migrating proj to a pure Rust implementation

CONs:

• unlike the rest of geo code in pure Rust, proj is an FFI wrapper (this is more of a philosophical point, but it was raised)

Move geo-types crate into a separate repo

PROs:

• Decouple geo-types from the dependent crates. Some crates are not part of the geo repo, creating an undesirable separation between "tightly coupled" crates in the same repo, and "version-coupled" crates in other repos.
• Enforces stricter version dependency between crates - all crates dependent on geo-types will have a clear version requirements, and a breaking change in geo-types would require a major version bump.
• breaking changes to geo-types won't affect downstream crates until they are ready to upgrade

CONs:

• There is no overall consistency between geo crates enforced by CI
• Breaking changes require many separate PRs into multiple repos, making the review process more complex.
• Reviewers will not see the potential impact of the change until geo-types is published, at which point it might be possible that the breaking change may require more work - requiring yet another breaking change release.

[nyurik]

Merge proj into this repo

(vote/discuss this option as replies to this thread)

[urschrei]

Hi @nyurik! Thanks for the detailed analysis of the present inconveniences we're facing. In order to move the discussion forward productively let me start by saying that we will not be merging proj into geo. It's a cpp library and we don't want a hard dependency on it. You characterise this as "more of a philosophical point". I see that as both factually incorrect, and a false distinction which shouldn't impede attempts to clearly think through the issue: a false distinction because software projects are inherently socio-technical endeavours, and they encode the philosophies and desires of their contributors at various scales and in their outputs. This is relevant because as a community, we like to work on a Rust library – it's motivating, enjoyable, and fulfilling for us. Factually incorrect because our current optional dependency on libproj in geo already causes problems when producing WASM versions of the library, for example.

Of course, we can't let the perfect be the enemy of the good: there is simply no substitute for libproj, and I'm quite confident in asserting that a Rust rewrite isn't happening in the foreseeable future: there's a time and financial constraint which could be solved with a few million dollars in developer salary, but more importantly a hard expertise constraint, in the sense that there aren't enough people with the requisite skills to do the work (I don't want to make any claims on behalf of Even, Kristian and others here, of course). There are parallel experiments underway, for instance Thomas Knudsen's geodesy project (https://github.com/busstoptaktik/geodesy), but as he notes "viewing RG as another PROJ, or PROJ RiiR, will lead to bad disappointment."

So we're "stuck" (and I mean this in the most positive sense) with libproj but we also want to keep it at arm's length, which is why it lives in separate crates (proj-sys and proj), and implements its own lightweight version of Coord – our goal is to provide the library to anyone in the Rust ecosystem whether they're geo{-types} users or not, while also making use of it ourselves in the most low-friction way possible.

[nyurik]

Thanks @urschrei! I agree about the philosophical aspect. Not sure why it will make it a hard dependency -- organizationally and compilation-wise it will remain the same, it will simply be in one repo vs two, allowing for a single PR to change both if needed. Regardless, its a moot point if we want to keep them separate.

Moving forward, it seems the only real "pass-through" dependency that goes geo-types -> proj -> geo is the core coordinate floating type. georust/proj#110 tries to make it consistent, but @rmanoka does not like conditional type definition. What would be a good solution here?

Lastly, all of my initial thoughts also apply to WKT lib, but unlike the proj, WKT seems to be fully in Rust. Would it make sense to merge it into the geo tree for the same reasons?

[nyurik]

Move geo-types crate into a separate repo

(vote/discuss this option as replies to this thread)

[nyurik]

General discussion

A thread to discuss thoughts not specific to any of the options. For alternative proposals please create a separate thread.