Issue #21311 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-51:
This feature proposal is quite exceptional. Because this is a feature strongly driven by @matz himself, and Ruby is matz's language.
@tagomoris has been working closely with Matz for several years to design and implement it. Although there are still many incomplete or rough parts, the decision has already been made.
I took some time before replying here to try to find the right words. Actually I think it is obvious what the 3 major problems are with this, but I will spell them out. It is great to hear matz was closely involved in the design of this feature. 1. However the design of such a big feature needs to be presented in advance, so it's not just the thoughts of 1/2/a few people but the Ruby community can participate, give feedback and help refine the feature design to make it better. Features are always better when more people are involved, a recent example is Prism (involved many people in the design, and it is widely used now) vs RubyVM::AST (involved very few people, used very little due to design flaws & impractical). 3. Alternatives should be considered early, to avoid "reinventing the wheel in a suboptimal way". The obvious alternative here is sub-interpreters, which is widely used (https://bugs.ruby-lang.org/issues/21311#note-47). In fact CRuby even had a `mvm` branch for this a long time ago. @tagomoris Was this considered, what advantages do namespaces have compared to sub-interpreters,? 2. The motivation needs to be clear and based on real-world use cases. This feature missed all 3 rather catastrophically: The current updated design was presented only days before it was merged. I find this irresponsible, especially when there are still so many problems with it. No wonder many people are reacting negatively to this. Granted, the previous design was explained in #19744. I found a critical flaw with that design (https://bugs.ruby-lang.org/issues/19744#note-74) and as a result it seems the feature design was reconsidered to address that. That part is good, however, this is only one of several serious concerns raised by many people in #19744. The biggest concern for any big feature should be what does it solve, is the motivation good enough to warrant the added complexity, performance overhead, etc? Let's look at the motivations from https://bugs.ruby-lang.org/issues/21311#note-28:
Mounting server-less applications (run on AWS Lambda, separated on processes in production) on a single app server for development
I can't see any significant benefit compared to just running each server-less application in its own process, as I said in https://bugs.ruby-lang.org/issues/21311#note-37. Maybe I'm missing some, then let's point those out, but clearly the advantages should be established way before merging the feature, i.e. early in the design process. There are many drawbacks to use namespaces for this use case, notably no proper isolation and no parallelism. I doubt any advantage can outweigh that. Also running things so differently than in production is bound to have issues (e.g. passes locally but fails in production).
Mounting two different revisions of an application for useful deployments (older and newer commits of an app)
Can do that with multiple processes, more compatible and even necessary if there is process-global state relied on (e.g. CWD). There can be a process receiving external requests, passing it to the two variants and comparing them, nothing new, it has been done many times. As far as I see the only advantage of namespaces for this is slightly easier communication but not fully compatible, lot more complexity, no parallelism, no proper isolation.
Mounting two different set of dependency versions of an application
Basically the same as above regarding trade-offs of using namespaces for this. Let's look at https://bugs.ruby-lang.org/issues/21311#Motivation too (already discussed in https://bugs.ruby-lang.org/issues/21311#note-13):
Avoiding name conflicts between libraries
Too rare to matter, this is a solved problem (a gem should only declare one top-level constant corresponding to the gem name), doesn't need any new solution.
Avoiding unexpected globally shared modules/objects
This is a problem (e.g. Oj global state/configuration) but namespaces are a poor solution for it: they duplicate the memory and load multiple copies of Oj (also making copies of the native library on the filesystem BTW). The proper solution there is like what the JSON gem did: provide an API to have that state locally (`JSON::Coder` or using a `JSON::State` instance explicitly). Also namespaces just wouldn't solve this if gems A and B depend on Oj and modify the Oj global state incompatibly, gems A and B would have to be modified just to use namespaces which is just not gonna happen (i.e. I don't think RubyGems or Bundler can do that transparently, gems A & B will refer to Oj with `Oj`, not `ns::Oj`. Loading A & B in namespaces just makes the same problem but for gems depending on A or B).
Multiple versions of gems can be required
This has been discussed extensively in #19744 and it seems pretty unhealthy for the Ruby ecosystem. I also don't see anyone going to decide to use namespaces to workaround some issue in some gem, forking the gem repository + fix on a branch is far more sensible and less risky than starting to use namespaces in your application to workaround some gem issue. @matz What real-world use cases do you see for Namespace? ---------------------------------------- Feature #21311: Namespace on read (revised) https://bugs.ruby-lang.org/issues/21311#change-113196 * Author: tagomoris (Satoshi Tagomori) * Status: Assigned * Assignee: tagomoris (Satoshi Tagomori) * Target version: 3.5 ---------------------------------------- This replaces #19744 ## Concept This proposes a new feature to define virtual top-level namespaces in Ruby. Those namespaces can require/load libraries (either .rb or native extension) separately from other namespaces. Dependencies of required/loaded libraries are also required/loaded in the namespace. This feature will be disabled by default at first, and will be enabled by an env variable `RUBY_NAMESPACE=1` as an experimental feature. (It could be enabled by default in the future possibly.) ### "on read" approach The "on write" approach here is the design to define namespaces on the loaded side. For example, Java packages are defined in the .java files and it is required to separate namespaces from each other. It can be implemented very easily, but it requires all libraries to be updated with the package declaration. (In my opinion, it's almost impossible in the Ruby ecosystem.) The "on read" approach is to create namespaces and then require/load applications and libraries in them. Programmers can control namespace separation at the "read" time. So, we can introduce the namespace separation incrementally. ## Motivation The "namespace on read" can solve the 2 problems below, and can make a path to solve another problem: * Avoiding name conflicts between libraries * Applications can require two different libraries safely which use the same module name. * Avoiding unexpected globally shared modules/objects * Applications can make an independent/unshared module instance. * Multiple versions of gems can be required * Application developers will have fewer version conflicts between gem dependencies if rubygems/bundler will support the namespace on read. (Support from RubyGems/Bundler and/or other packaging systems will be needed) For the motivation details, see [Feature #19744]. ## How we can use Namespace ```ruby # app1.rb PORT = 2048 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 2048 # app2.rb class Number def double = self * 2 end PORT = 2048.double class App def self.port = ::PORT def val = PORT.double.to_s end p App.port # 4096 # main.rb - executed as `ruby main.rb` ns1 = Namespace.new ns1.require('./app1') # 2048 ns2 = Namespace.new ns2.require('./app2') # 4096 PORT = 8080 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 8080 p App.new.val # "8080" p ns1::App.port # 2048 p ns1::App.new.val # "2048" p ns2::App.port # 4096 p ns2::App.new.val # "8192" 1.double # NoMethodError ``` ## Namespace specification ### Types of namespaces There are two namespace types, "root" and "user" namespace. "Root" namespace exists solely in a Ruby process, and "user" namespaces can be created as many as Ruby programmers want. ### Root namespace Root namespace is a unique namespace to be defined when a Ruby process starts. It only contains built-in classes/modules/constants, which are available without any `require` calls, including RubyGems itself (when `--disable-gems` is not specified). At here, "builtin" classes/modules are classes/modules accessible when users' script evaluation starts, without any require/load calls. ### User namespace User namespace is a namespace to run users' Ruby scripts. The "main" namespace is the namespace to run the user's `.rb` script specified by the `ruby` command-line argument. Other user namespaces ("optional" namespaces) can be created by `Namespace.new` call. In user namespace (both main and optional namespaces), built-in class/module definitions are copied from the root namespace, and other new classes/modules are defined in the namespace, separately from other (root/user) namespaces. The newly defined classes/modules are top-level classes/modules in the main namespace like `App`, but in optional namespaces, classes/modules are defined under the namespace (subclass of Module), like `ns::App`. In that namespace `ns`, `ns::App` is accessible as `App` (or `::App`). There is no way to access `App` in the main namespace from the code in the different namespace `ns`. ### Constants, class variables and global variables Constants, Class variables of built-in classes and global variables are also separated by namespace. Values set to class/global variables in a namespace are invisible in other namespaces. ### Methods and procs Methods defined in a namespace run with the defined namespace, even when called from other namespaces. Procs created in a namespace run with the defined namespace too. ### Dynamic link libraries Dynamic link libraries (typically .so files) are also loaded in namespaces as well as .rb files. ### Open class (Changes on built-in classes) In user namespaces, built-in class definitions can be modified. But those operations are processed as copy-on-write of class definition from the root namespace, and the changed definitions are visible only in the (user) namespace. Definitions in the root namespace are not modifiable from other namespaces. Methods defined in the root namespace run only with root-namespace definitions. ## Enabling Namespace Specify `RUBY_NAMESPACE=1` environment variable when starting Ruby processes. `1` is the only valid value here. Namespace feature can be enabled only when Ruby processes start. Setting `RUBY_NAMESPACE=1` after starting Ruby scripts performs nothing. ## Pull-request https://github.com/ruby/ruby/pull/13226 -- https://bugs.ruby-lang.org/