Issue #12138 has been updated by Josh Cheek.


Robert A. Heiler wrote:
> +1 for the spirit of the suggestion
> 
> Perhaps ruby 3.x will also feature some more advanced import-like system
> fitting to ruby. :) Manipulating environments or objects-in-environments
> would be nice.
> 
> I have no particular strong feeling in favour or disfavour of the syntax
> but it seems a bit hard to remember, the
> (filename, cbase: SomeMod, cref: someMod, binding: SomeMod)

Aye, I have no preference either, I chose those names just to make it clear what things I want to be able to set. Ie `RSpec.describe ...` would be fine if I could choose what object `RSpec` evaluates to in that file. Or toplevel method defs would be fine if I could choose what object they get defined on. By giving it a binding to evaluate within, I can choose what its `self` should be, and provide it with local variables. I don't particularly care how this is achieved.

----------------------------------------
Feature #12138: Support `Kernel#load_with_env(filename, cbase: SomeMod, cref: someMod, binding: SomeMod) # => obj`
https://bugs.ruby-lang.org/issues/12138#change-57307

* Author: Josh Cheek
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Ruby's `require` and `load` methods currently only return `true`, which means that any code being loaded must affect the global namespace, or have the global namespace affected for it to interact with.

This means that to load data, like a gemspec, you have to read the file in and eval it:
* [Rubygems](https://github.com/ruby/ruby/blob/0534b970bc83814e77ea4bd8ba9b2d31fefc9b1e/lib/rubygems/specification.rb#L1164)
* [Bundler](https://github.com/bundler/bundler/blob/5e2e2ff089af4875c54b27cfb5d4286471dff125/lib/bundler.rb#L395)

To load a plugin or configuration, you have to modify a global object:
* [Railties](https://github.com/rails/rails/blob/e2f08a1c0a9d1dc2f27d1dfcd3c9937f4190554a/railties/lib/rails/engine.rb#L356-#L358) hook into subclassing
* [RSpec](https://github.com/rspec/rspec-core/blob/f54edeed49799042b8fffddb278466fb7185314e/lib/rspec/core/dsl.rb#L37-L47) tests have to be declared to a global object
* [Minitest](https://github.com/seattlerb/minitest/blob/baf6010053279f75f561f6a599d8837151327588/lib/minitest.rb#L262-L265), too
* [Rake](https://github.com/ruby/rake/blob/7c9014e5559e846e9ffee1cf1584c4454374dd70/lib/rake/dsl_definition.rb#L194) extends main to store results on a [global object](https://github.com/ruby/rake/blob/7c9014e5559e846e9ffee1cf1584c4454374dd70/lib/rake/dsl_definition.rb#L58-#L60)

It's why gems have to be built the way they do, to avoid colliding with other code in the global namespace (fwiw, I've seen a computer segfault when the person unwittingly write their own Queue class). Which is also why we can't load multiple versions of a gem in the same namespace.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>