From: "Eregon (Benoit Daloze)" Date: 2022-02-03T11:02:40+00:00 Subject: [ruby-core:107460] [Ruby master Bug#18567] Depending on default gems when not needed considered harmful Issue #18567 has been updated by Eregon (Benoit Daloze). vo.x (Vit Ondruch) wrote in #note-11: > 1) Not specifying dependencies prevents major changes. If there is default gem A of version 1.5.2 and there should be major update in future version of Ruby, lets say to the version 2.0.0. If some gem specified the dependency on A ~> 1.0, there would not be problem, it could keep using the old version. But your proposal is going against this, so I am not sure what would be the suggestion for this case. It's very unlikely those parts of stdlib would have major changes, and even if they do feature checking is always better to support more Ruby versions (e.g., `respond_to?`). Many scripts/programs/gems out depend on these 4 stdlibs, they do not specify the dependencies on such basic default gems, and the majority of them will not specify such dependencies needlessly in the future either. And if a feature of a specific version of that default gem, then specifying the dependency makes sense, but there is no need currently. > 2) WEBrick used to be part of StdLib while it is not anymore. It would not be problem if every app/library specified this dependency prior the removal, but you suggest against it. I believe these 4 gems will never become external. But even if at some point we want to make them external, we can add the dependencies then. That will be very few changes compared to the many users that would need to adapt their program for the removal of such a default gem from stdlib. > I said it in other places too but It's also my opinion that dependencies on default gems should be explicit, for the reasons stated by others. The vast majority of gems out there (is there even one popular non-stdlib gem doing that?) don't specify needless dependencies on default gems, so it really doesn't seem worth it for just a few stdlib gems to do it. Without the explicit dependency the version used is the well known one in stdlib, and all of stdlib might be/is used without explicit dependencies. There is no need or gain to have dependencies on these gems now, especially with an unbounded version requirement. And it actually hurts compatibility as explained. But somehow people think it's worth sacrificing compatibility just to sometimes have a default gem version in a lockfile when one of these stdlib gems is used? ---------------------------------------- Bug #18567: Depending on default gems when not needed considered harmful https://bugs.ruby-lang.org/issues/18567#change-96362 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- CRuby over time moves more and more code to default gems, to bundled gems and or even stops shipping some gems which used to be stdlibs (#5481). I believe the main motivation for that is being to fix security issues without needing to make a CRuby release, and that makes sense. There are however multiple unwanted side effects of this: 1. Removing gems from stdlib (e.g., #17873) is a breaking change, which makes upgrading to a new Ruby version more difficult. I think this should only be done if there is a clear gain. Being a default gem is already enough to fix a security issue without a CRuby release. 2. When any gem depends on a default gem, it tends to break on all Ruby implementations except CRuby, and for older Ruby versions. Let's focus on this second point. There can be good reasons to depend on a specific version (or ~>/>=) of a default gem, for instance to ensure a given security issue is addressed. In other cases, I think there is no value to depend explicitly on a default gem, it would work without an explicit dependency since it is still "in stdlib". And it is actually harmful to depend on default gems for JRuby, TruffleRuby and older Ruby versions, because the default gem does typically not work there yet, but the stdlib works just fine! The reason for that is simple, those gems used to be stdlib and so were implemented directly in the Ruby implementation. Also depending on default gem will typically be redundant with what's in stdlib, which is then a waste of network, time and disk. For larger default gems (e.g., openssl), I believe the solution is those gems to support JRuby, TruffleRuby, etc. This is useful so the behavior for a given version of the gem is compatible between Ruby implementations, has the same security fixes, etc. It is however a large effort and overhead to do this, and it only makes sense if people are going to need to depend on such a gem explicitly (either for security or new features in a given version), otherwise the version in stdlib is good enough and much simpler. Here are I think some clear cases of default gems which are clearly more overhead than what they gain: * io-wait: just a few methods very tight to IO internals, should really be core * io-nonblock just a few methods very tight to IO internals, should really be core * digest: has a public header and so versioning it doesn't work. Also it makes sense to reuse e.g. MessageDigest on JVM for better performance. * strscan: this accesses a lot of Regexp internal, it would fit better in each implementation repo as a non-gem stdlib. These are all small, they are all fairly stable, and it's unclear why they are even default gems in the first place. They also seem fairly unlikely to have security issues. So this is what I propose: * Do not depend on default gems unless necessary (for security or feature), or unless we know the next version of Ruby will no longer ship that gem. An example is `net-protocol` depending needlessly on `io-wait`, I'll make a PR for that. * I think those gems listed just above should no longer be default gems in the future to clarify the situation. They should either be core or regular non-gem stdlib. -- https://bugs.ruby-lang.org/ Unsubscribe: