[#115212] [Ruby master Bug#19983] Nested * seems incorrect — "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>

Issue #19983 has been reported by Eregon (Benoit Daloze).

9 messages 2023/11/01

[#115226] [Ruby master Bug#19984] `make test-bundler-parallel` fails with ` --enable-shared` — "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>

Issue #19984 has been reported by vo.x (Vit Ondruch).

7 messages 2023/11/02

[#115227] [Ruby master Feature#19985] Support `Pathname` for `require` — "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>

Issue #19985 has been reported by vo.x (Vit Ondruch).

14 messages 2023/11/02

[#115259] [Ruby master Bug#19990] Could we reconsider the second argument to Kernel#load? — "fxn (Xavier Noria) via ruby-core" <ruby-core@...>

SXNzdWUgIzE5OTkwIGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGZ4biAoWGF2aWVyIE5vcmlhKS4NDQoN

9 messages 2023/11/06

[#115304] [Ruby master Feature#19993] Optionally Free all memory at exit — "HParker (Adam Hess) via ruby-core" <ruby-core@...>

Issue #19993 has been reported by HParker (Adam Hess).

8 messages 2023/11/08

[#115333] [Ruby master Misc#19997] DevMeeting-2023-11-30 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #19997 has been reported by mame (Yusuke Endoh).

15 messages 2023/11/10

[#115334] [Ruby master Feature#19998] Emit deprecation warnings when the old (non-Typed) Data_XXX API is used — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>

Issue #19998 has been reported by byroot (Jean Boussier).

12 messages 2023/11/10

[#115388] [Ruby master Feature#20005] Add C API to return symbols of native extensions resolved from features — "tagomoris (Satoshi Tagomori) via ruby-core" <ruby-core@...>

Issue #20005 has been reported by tagomoris (Satoshi Tagomori).

14 messages 2023/11/14

[#115422] [Ruby master Bug#20009] Marshal.load raises exception when load dumped class include non-ASCII — "ippachi (Kazuya Hatanaka) via ruby-core" <ruby-core@...>

SXNzdWUgIzIwMDA5IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGlwcGFjaGkgKEthenV5YSBIYXRhbmFr

14 messages 2023/11/19

[#115428] [Ruby master Feature#20011] Reduce implicit array allocations on caller side of method calling — "jeremyevans0 (Jeremy Evans) via ruby-core" <ruby-core@...>

Issue #20011 has been reported by jeremyevans0 (Jeremy Evans).

8 messages 2023/11/20

[#115438] [Ruby master Misc#20013] Travis CI status — "jaruga (Jun Aruga) via ruby-core" <ruby-core@...>

Issue #20013 has been reported by jaruga (Jun Aruga).

51 messages 2023/11/21

[#115484] [Ruby master Bug#20022] GC.verify_compaction_references does not actually move alll objects — "kjtsanaktsidis (KJ Tsanaktsidis) via ruby-core" <ruby-core@...>

Issue #20022 has been reported by kjtsanaktsidis (KJ Tsanaktsidis).

7 messages 2023/11/27

[#115491] [Ruby master Feature#20024] SyntaxError subclasses — "kddnewton (Kevin Newton) via ruby-core" <ruby-core@...>

Issue #20024 has been reported by kddnewton (Kevin Newton).

17 messages 2023/11/27

[#115525] [Ruby master Feature#20027] Range Deconstruction — "stuyam (Stuart Yamartino) via ruby-core" <ruby-core@...>

Issue #20027 has been reported by stuyam (Stuart Yamartino).

8 messages 2023/11/28

[#115552] [Ruby master Misc#20032] Propose @kjtsanaktsidis as a commiter — "jeremyevans0 (Jeremy Evans) via ruby-core" <ruby-core@...>

Issue #20032 has been reported by jeremyevans0 (Jeremy Evans).

15 messages 2023/11/30

[ruby-core:115281] [Ruby master Feature#19972] Install default/bundled gems into dedicated directories

From: "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>
Date: 2023-11-06 17:26:10 UTC
List: ruby-core #115281
Issue #19972 has been updated by vo.x (Vit Ondruch).


Dan0042 (Daniel DeLorme) wrote in #note-5:
> I'm not against the idea, but there's already quite few a directories for ruby libraries and TBH it's getting a bit confusing.
> 
> lib/ruby/3.2.0
> lib/ruby/gems/3.2.0
> lib/ruby/site_ruby/3.2.0/x86_64-linux
> lib/ruby/vendor_ruby/3.2.0/x86_64-linux

These are for Ruby *libraries* as you say. Not for gems. On Fedora, we are occasionally using the vendor dir for our packages, but we prefer the gemified versions of libraries, no matter if RPM managed or `gem install`ed.

For gems, the paths are

~~~
$ gem env

... snip ...

  - GEM PATHS:
     - /usr/local/lib/ruby/gems/3.3.0+0
     - /builddir/.local/share/gem/ruby/3.3.0+0

... snip ...
~~~

Although RubyGems know `vendor` dir, which is not even listed by `gem env`.

> lib/ruby/default_gems/3.2.0 **new!!!**

Yep, something like this would be listed among the `GEM PATHS` by the command above. Plus also `bundled_gems` dir.

> from https://stdgems.org/
> > * Default gems: These gems are part of Ruby and you can always require them directly. You cannot remove them. They are maintained by Ruby core.
> > * Bundled gems: The behavior of bundled gems is similar to normal gems, but they get automatically installed when you install Ruby. They can be uninstalled and they are maintained outside of Ruby core.

I don't think that https://stdgems.org/ is relevant here, because it is 3rd party site. The proper documentation is here:

https://github.com/ruby/ruby/blob/14bf7164a69944b4e54aa2502cb5749d700505e5/doc/standard_library.rdoc?plain=1#L24
https://github.com/ruby/ruby/blob/14bf7164a69944b4e54aa2502cb5749d700505e5/doc/standard_library.rdoc?plain=1#L107

And there are differencies such as: "They can be uninstalled" vs "They can be uninstallable from Ruby installation."
 
> According to the above, bundled gems are closer in behavior to user gems than to default gems; does it really make sense to mix bundled+default?

My proposal is to install them into separate directories. But maybe the remark was not directed to me :)

> From my reading of the situation, it seems like there should be
> 1. a directory for default gems
> 2. the regular "gems" directory for bundled gems and root-installed gems
> 3. Gem.user_dir for user-installed gems

My proposal is to make this flexible enough to allow the situation as you describe, while I'd prefer:

1. a directory for default gems
2. a directory for bundled gems
3. directory for system wide installed gems
4. dir for user installed gems

Please note that I deliberately not using terms such as "root-installed gems" or "Gem.user_dir for user-installed gems" to prevent too much implications. And if you look at my POC, it actually does not change anything in RubyGems, it just merely changes configuration.

----------------------------------------
Feature #19972: Install default/bundled gems into dedicated directories
https://bugs.ruby-lang.org/issues/19972#change-105197

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
I think that the current situation, where the same directory (lets call it `Gem.default_dir`) is used for default/bundled gems as well as for user installed gems, is suboptimal. During the times, this has caused us quite some issue on Fedora. Historically, we redefined the `Gem.default_dir` to user home directory, to avoid the mixing of system gems and user installed gems. Unfortunately, with advent of default/bundled gems, we were facing issues that these gems were suddenly not listed, etc. I am realizing this issue in full once again since the "user install" RubyGems feature has landed [1]. I also think that we have arrived to this situation by evolution, not by design.

Therefore my proposal is:

Keep the `Gem.default_dir` for user `gem install`ed gems and lets install default and bundled gems into separate dedicated directories. Have separate `Gem.bundled_gems_dir` and `Gem.default_gems_dir` structures.

Of course, if `Gem.default_dir == Gem.bundled_gems_dir == Gem.default_gems_dir`, we still can have the current layout.

I have a simple POC here:

https://github.com/ruby/ruby/pull/8761

BTW I have reported it here, because I think that RubyGems provides all it is needed. So it is not RubyGems ticket after all. However, I believe that RubyGems could benefit from this long term and some simplifications/cleanups would be possible.

[1]: https://github.com/rubygems/rubygems/pull/5327



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

In This Thread