-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make lazy_static optional? #46
Comments
It's nice to trim down dependencies, but I'm wondering how many people actually want to use this library without the WGS84 ellipsoid. Do you have this use case? Can you tell me more about it? lazy_static is a very small, common, and well maintained dependency, so I'd guess that it's unlikely to cause any real damage. More likely, in my estimation, is that some well meaning person will disable all the default features on their dependencies and then wonder why this library no longer works for them. |
I have this exact case where
That's why I'm not strongly arguing for implementing this change, but rather discussing it as something to consider.
Personally, I would assume that mostly experienced Rust users disable default features and expect things to break because of that, and look for the smallest set of necessary features for their use-case. |
It is possible just pre-calculate
and add unit test to verify that it equals to So it would be possible unconditionally remove |
It should be possible to replace the |
Fixed in #52 |
lazy_static
is used once in the whole crate - to declarewgs84
ellipsoid. Solazy_static
is not necessary for the main functionality of the crate, but is introduced as a compulsory dependency.Having a reference ellipsoid in the crate is definitely a useful feature to not require from user to define WGS84 manually every time (and it's also useful for tests). But the introduction of a additional dependency for one object seems like a good spot for improvements.
My idea is to add pre-defined ellipsoids (and thus
lazy_static
) as a default feature. This way no functionality will change for users, but they will be able to use one less dependency when needed.I can create a PR if such solution is welcome.
The text was updated successfully, but these errors were encountered: