MSRV policy about geo HOT 12 OPEN

I think that table might be misleading because it shows optional and transitive dependencies. cargo outdated -R will show only direct dependencies, while cargo tree -d will show the duplicate ones. We're not compiling three different versions of generic-array, as it might appear.

On our side, arbitrary is the only remaining thing to bump. And you can see it has no outdated deps.

from geo.

I don't think so, only confusion. Maybe we can schedule it for the next breaking release?

from geo.

Would that improve the build times or reduce the number of dependencies?

In the cold light of day, syncing up version numbers in my libraries solved all the issues, but I could ONLY do that as I am the maintainer of those 3 libraries, in the general case the problem is intractable and persists until someone works their way upstream, through several open source communities/projects ... a tough ask.

The only valid response to this problem ... is known,

"In your own code base be extremely circumspect when pulling in a new dependency, make sure the community is vibrant, and has well considered MSRV policy.

I am not a security expert but the other motivation for the change I am advocating is "Simplified" is better/ "more secure" if only because now needless features increase the attack surface, and or make the security review more error prone.

Along those lines, If I remember correctly floppy disk drive support in Linux was considered working and stable - until a zero day was spotted .. then response was just drop the whole floppy module.

from geo.

PS: we could probably drop support for that old rstar, and I'm not sure what we're using the previous version of geo-types for (called gt-prev in the manifest).

from geo.

Thanks for all the comments, that is indeed where my focus was shifting.. it is really helpfully to know when others share or don't share what I am thinking...

from geo.

I think your concerns are valid in general, but not really applicable today.

Next steps would probably be to drop 1.58 from CI and update rust-version in the manifests, then bump arbitrary, then maybe drop the old rstar.

from geo.

I appreciate what you say about

cargo outdated -R

My context : -

I have written 3 crate/libraries which all depend of "geo". When I use those libraries to write a application, well the dependency tree looks overly inflated and compile performance is just a nightmare.

Last month, two levels downstream - I took this approach, and de-duped my own library -- It was a big improvement .. but still not a fix.

so two levels down cargo outdated .. is a real truth teller.

and when you say

but not really applicable today.

I think differently, I know this can be helpful.

When I analyse my own problem I know I can only make real progress until I move this PR forward #908 .

That PR will limit this project to "Rust 2021 Edition"

But hey each PR should have a singular focus

from geo.

Thanks for moving us into the ✨Future✨ @martinfrances107!

PS: we could probably drop support for that old rstar, and I'm not sure what we're using the previous version of geo-types for (called gt-prev in the manifest).

I think we decided this would entail a breaking bump to geo-types. Though we pretty often and eagerly bump the geo crate, we're more conservative with geo-types. geo-types is a relatively widely used crate that we encourage library maintainers to integrate with. Whenever we bump it, that change needs to ripple across the ecosystem. We're like a guest staying in their home, so we try to be polite.

That said, if there's a good reason to bump it, we should. Is the optional old version of rstar causing some kind of problem?

from geo.

I have written 3 crate/libraries which all depend of "geo". When I use those libraries to write a application, well the dependency tree looks overly inflated and compile performance is just a nightmare.

What duplicate dependencies does geo bring into your libraries?

from geo.

Before I act, I just want to give the rationale, to firm up the "probably" in this quote

we could probably drop support for that old rstar,

Copied from the code base, here is the explanation for the rstar / namespaced-features

[features]
# Prefer `use-rstar` feature rather than enabling rstar directly.
# rstar integration relies on the optional approx crate, but implicit features cannot yet enable other features.
# See: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#namespaced-features

When I follow the link I see

Namespaced features has been stabilized in the 1.60 release

So ignoring my drives, the wider case is a maintenance patch is to simplify the use of rstar

from geo.

Would that improve the build times or reduce the number of dependencies?

from geo.

#968 we now have a candidate PR ...

Opps I need to update the change log, at the very least...

from geo.