Closed mattdrose closed 4 years ago
Thank you for the issue. It is by design. We believe application developers should be also responsible for the libraries they use in their apps, after all, they chose to use those dependencies and are responsible for making sure that choice is still the right one.
If a library in their app is using deprecated code either the app developer should open a PR to the library, or they should report an issue. In case it is already fixed this failure is also useful to get the app developers to upgrade the dependencies.
We are aware that some cases it is not possible to do those things, like in the case you pointed. But that is likely because the dependency is not maintained anymore or because it is an old version. In those cases either the app need to remove that dependency in favor of something that is maintained, or they need to upgrade. It may take time and that is is why we are ignoring that warning in the cause you linked.
Oops, I'm was not supposed to close this
Thanks for the quick reply. Knowing it was design, this is a discussion rather than a bug.
Your reasoning seems like good practice, and I agree with the reasoning. In practice though, there are a couple caveats I've noticed:
What are your thoughts on making this behaviour opt-in or opt-out? Or even possibly detecting whether a library is already maintaining their own shitlist, and not throwing errors if this is true.
This gem doesn't target libraries, only apps. So we would not have shitlists inside the libraries.
As the deprecation_toollkit only run in the test environment, even if a library had a shitlist, users would still see deprecations in production and development, and libraries using deprecated code would still have to change their code, otherwise they would be annoying the users that would likely open issues to them fix the deprecations.
This is what already happens today, and the beginning of the Ruby community, and in my opinion is one of the best things of the Ruby ecosystem, we evolve fast and adopt early.
If a consequence of this gem existing is that libraries keep using deprecated code I'd probably unpublish this library 😄.
All that said, the goal of this gem is make easier for application developers know which code they use in their application will be broken when the deprecated code is removed from the source, and progressively fix this code. This includes code on libraries and in the application. Ignoring deprecated code on libraries would just make this future breakage invisible to the app developers, what would defeat the reason why we wrote this gem.
Closing this since the gem is doing its job, and I don't have anything left to say :P. Thanks for hearing me out and walking me through your reasoning 🙏.
Behaviour
DeprecationToolkit
is throwing errors if a consumer is using a deprecated method. For example, if FooApp is using Rails ~6.0, and a dependency is usingModule#parent
, FooApp will throw an error.Expected behaviour
DeprecationToolkit
only throws an error if there's a deprecated method used in the source code. For example, FooApp shouldn't throw and error if a dependency is usingModule#parent
, but rather only ifModule#parent
is being used in the source code.What people are doing to solve it
I see apps like core are ignoring these warnings.
Opinion
I'm not sure if this is by design or not, but if it is I don't think it should be default behaviour.
Shitlists are a great pattern to update your codebase—but it's not the task of an app to also update their dependencies codebases as well. For example, if Rails deprecates a method, it should be up to the app maintainers to update their codebase, and separately up to the gem maintainers to update their own codebase. In this case, each maintainer would create a shitlist for their respected codebases.