February 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:112467] [Ruby master Feature#18841] Proposal: autoload_relative
by rubyFeedback (robert heiler) 17 Feb '23

17 Feb '23

Issue #18841 has been updated by rubyFeedback (robert heiler). I am not sure we should add more methods from within that family (autoload-family). Personally I would even remove require_relative, but I guess too much code depends on it nowadays. ---------------------------------------- Feature #18841: Proposal: autoload_relative https://bugs.ruby-lang.org/issues/18841#change-101912 * Author: fxn (Xavier Noria) * Status: Open * Priority: Normal ---------------------------------------- In my experience, autoloads often reflect an existing hierarchical structure. If a project does not use Zeitwerk, and the user declares autoloads for a class or module, chances are they are for child constants. As an example, see the [`ActiveRecord` module](https://github.com/rails/rails/blob/main/activerecord/lib/active_re…. (Those ones do not have a second argument because we define wrapper that derives it by convention, [here](https://github.com/rails/rails/blob/main/activesupport/lib/active_sup…) I think it would be convenient to have an `autoload_relative` in the line of `Kernel#require_relative`. It would make existing patterns more concise, and as a practical consequence, you skip `$LOAD_PATH` lookups too. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112466] [Ruby master Feature#19024] Proposal: Import Modules
by rubyFeedback (robert heiler) 17 Feb '23

17 Feb '23

Issue #19024 has been updated by rubyFeedback (robert heiler). Personally I think it may be better to leave require(), load() and require_relative() unchanged as-is, and instead add a new, more sophisticated way for ruby to handle loading of stuff in general. That one should then ideally be as flexible as possible, and "extensible" for the future. It could then also allow all of our needs and wants. Many years ago, for instance, I wanted to be able to load up a specific module, but instantly, upon load-time, assign it a new different name. We can kind of simulate that way e. g. require 'foobar' Barfoo = Foobar # and then setting Foobar to nil, I suppose, or # something like that But I wanted that on the require/load situation. We could also integrate autoload-like behaviour into it. And so on and so forth. That could also mean to load ruby code "outside" of any "namespace". Such as "anonymous loading" not polluting the namespace. I am not sure we should add "import" as such, though. People will ask when to use include, and extend, and then import. So I kind of agree with fxn that we should leave require and load as it is, and instead think about more flexible loading/requiring of code as-is. Another feature I wanted to have is that we can assign "authors" to a namespace - not in a way to deny people from using them, but simply to be able to track who made modifications where and when. In some ways this is similar to how refinements can be thought of - we can think of them as "isolated namespace changes" but allowing us more control over the code changes (if we ignore the syntax; I always found the syntax odd for refinements). Perhaps we should create a more unified proposal eventually that can unify all the different ideas, pros and cons, for matz to think about what the best approach would be. One thing austin wrote: > I don’t see any value in namespacing beyond what Ruby has > through modules and classes. I certainly don’t see any > value in the ability to load more than one version of a > piece of code at a time under a different namespace (this > is, IMO, one of the worst parts of JavaScript). Well, refinements already does that to some extent; and I can see the potential value in knowing who made modifications where and when. Right now we all have one unified namespace. This can lead to problems sometimes. I agree it is not a huge problem per se, but when I write: class Colors And some other package is: module Colors and I already included that, then there are some problems. (Or, both use class, or module, and then I may overwrite some toplevel method or a similar problem.) It's not a huge problem per se, mind you, but in these cases, being able to "tap" into a class or module and see where changes were made, when, by whom, and in which package/file, can be useful in my opinion. That is not to say I agree with the proposal here per se, but I wanted to comment on whether there may be use cases - and I think there are. I don't know of a good syntax-way to tap into any of that though. I just think we should be open about different ways how to load up code in ruby, because there are definitely use cases that are not fully covered by require and load. (I use require() about 98% of the time, and I avoid autoload, because I found that the cognitive load of having to remember how to use it offsets the benefits it brings; I also don't need require_relative. I do sometimes need to use load(), e. g. dynamic reloading of code if you need it, but I can see different use cases most assuredly.) ---------------------------------------- Feature #19024: Proposal: Import Modules https://bugs.ruby-lang.org/issues/19024#change-101911 * Author: shioyama (Chris Salzberg) * Status: Open * Priority: Normal ---------------------------------------- There is no general way in Ruby to load code outside of the globally-shared namespace. This makes it hard to isolate components of an application from each other and from the application itself, leading to complicated relationships that can become intractable as applications grow in size. The growing popularity of a gem like [Packwerk](https://github.com/shopify/packwerk), which provides a new concept of "package" to enforce boundaries statically in CI, is evidence that this is a real problem. But introducing a new packaging concept and CI step is at best only a partial solution, with downsides: it adds complexity and cognitive overhead that wouldn't be necessary if Ruby provided better packaging itself (as Matz has suggested [it should](https://youtu.be/Dp12a3KGNFw?t=2956)). There is _one_ limited way in Ruby currently to load code without polluting the global namespace: `load` with the `wrap` parameter, which as of https://bugs.ruby-lang.org/issues/6210 can now be a module. However, this option does not apply transitively to `require` calls within the loaded file, so its usefulness is limited. My proposal here is to enable module imports by doing the following: 1. apply the `wrap` module namespace transitively to `require`s inside the loaded code, including native extensions (or provide a new flag or method that would do this), 2. make the `wrap` module the toplevel context for code loaded under it, so `::Foo` resolves to `<top_wrapper>::Foo` in loaded code (or, again, provide a new flag or method that would do this). _Also make this apply when code under the wrapper module is called outside of the load process (when `top_wrapper` is no longer set) — this may be quite hard to do_. 3. resolve `name` on anonymous modules under the wrapped module to their names without the top wrapper module, so `<top_wrapper>::Foo.name` evaluates to `"Foo"`. There may be other ways to handle this problem, but a gem like Rails uses `name` to resolve filenames and fails when anonymous modules return something like `#<Module: ...>::ActiveRecord` instead of just `ActiveRecord`. I have roughly implemented these three things in [this patch](https://github.com/ruby/ruby/compare/master...shioyama:ruby:import_m…. This implementation is incomplete (it does not cover the last highlighted part of 2) but provides enough of a basis to implement an `import` method, which I have done in a gem called [Im](https://github.com/shioyama/im). Im provides an `import` method which can be used to import gem code under a namespace: ```ruby require "im" extend Im active_model = import "active_model" #=> <#Im::Import root: active_model> ActiveModel #=> NameError active_model::ActiveModel #=> ActiveModel active_record = import "active_record" #=> <#Im::Import root: active_record> # Constants defined in the same file under different imports point to the same objects active_record::ActiveModel == active_model::ActiveModel #=> true ``` With the constants all loaded under an anonymous namespace, any code importing the gem can name constants however it likes: ```ruby class Post < active_record::ActiveRecord::Base end AR = active_record::ActiveRecord Post.superclass #=> AR::Base ``` Note that this enables the importer to completely determine the naming for every constant it imports. So gems can opt to hide their dependencies by "anchoring" them inside their own namespace, like this: ```ruby # in lib/my_gem.rb module MyGem dep = import "my_gem_dependency" # my_gem_dependency is "anchored" under the MyGem namespace, so not exposed to users # of the gem unless they also require it. MyGemDependency = dep #... end ``` There are a couple important implementation decisions in the gem: 1. _Only load code once._ When the same file is imported again (either directly or transitively), "copy" constants from previously imported namespace to the new namespace using a registry which maps which namespace (import) was used to load which file (as shown above with activerecord/activemodel). This is necessary to ensure that different imports can "see" shared files. A similar registry is used to track autoloads so that they work correctly when used from imported code. 2. Toplevel core types (`NilClass`, `TrueClass`, `FalseClass`, `String`, etc) are "aliased" to constants under each import module to make them available. Thus there can be side-effects of importing code, but this allows a gem like Rails to monkeypatch core classes which it needs to do for it to work. 3. `Object.const_missing` is patched to check the caller location and resolve to the constant defined under an import, if there is an import defined for that file. To be clear: **I think 1) should be implemented in Ruby, but not 2) and 3).** The last one (`Object.const_missing`) is a hack to support the case where a toplevel constant is referenced from a method called in imported code (at which point the `top_wrapper` is not active.) I know this is a big proposal, and there are strong opinions held. I would really appreciate constructive feedback on this general idea. Notes from September's Developers Meeting: https://github.com/ruby/dev-meeting-log/blob/master/DevMeeting-2022-09-22.m… See also similar discussion in: https://bugs.ruby-lang.org/issues/10320 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112441] [Ruby master Feature#13620] Simplifying MRI's build system: always make install
by Eregon (Benoit Daloze) 15 Feb '23

15 Feb '23

Issue #13620 has been updated by Eregon (Benoit Daloze). FWIW, here is another terrible hack due to trying to run before files have a proper Ruby home structure: https://github.com/ruby/ruby/commit/a2c66f52f402cb58372e271226f3341065561e53 and reported as #19158. ---------------------------------------- Feature #13620: Simplifying MRI's build system: always make install https://bugs.ruby-lang.org/issues/13620#change-101885 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- Hello all, I've been bitten recently when modifying ruby/spec or in #13570 by the sheer number of different configurations to build and test in MRI. Currently, I know 4 of them, and I can tell you it is a big headache to make it work on all of them: * in-source-dir build, running tool/runruby.rb * in-source-dir build, running the installed ruby * out-of-source build, running tool/runruby.rb * out-of-source build, running the installed ruby I just compiled latest MRI this morning, and here are the times: * time make -j 8: make -j 8 373.22s user 30.88s system 404% cpu 1:39.99 total * time make -j 8 install-nodoc make -j 8 install-nodoc 3.29s user 0.55s system 259% cpu 1.477 total So I am wondering, should we just test with the installed ruby since installing it takes only marginally more time than building? The current complexity of runruby.rb, the generated ./rbconfig.rb, etc, all to support testing from the built ruby seems not worth it. It also means all the tests need to accommodate this different layout and are essentially testing a ruby layout that nobody uses in production. On the other hand, testing the installed ruby would test something which is much closer to what is released and used in production, and massively simplify the setup to test by making installed layout assumptions hold (e.g.: RbConfig.ruby points to the current ruby and ruby needs no flags to execute correctly). Did I miss something? I also wish we could choose one of in-source/out-of-source and not having to support both, but let's talk about make/make install first. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112426] [Ruby master Feature#18980] Re-reconsider numbered parameters: `it` as a default block parameter
by rubyFeedback (robert heiler) 14 Feb '23

14 Feb '23

Issue #18980 has been updated by rubyFeedback (robert heiler). If I recall correctly I suggested @1 @2 and so forth. At a later time _1 _2 and so forth was added, which is not entirely the same. I then realised that the suggestion was actually much older than my suggestion, and the ruby core team often said they may build upon suggestions and modify it. What surprised me was that one of my use case was not implemented, at the least back then. Which was: @large_collection_as_an_array.each {|cats_with_a_fluffy_tail, dogs_with_cute_ears, ships_with_red_painting, cars_without_a_door| } For such a situation, in particular in IRB as well as in quick debugging, I wanted to be able to refer to the element at hand quickly, without having to remember the name as such. So I could then do: pp @1 pp @3 And so on. Unfortunately it seems as if that was not considered, and it was (back then at the least) made forbidden to assign proper (long) names to the block variables. The syntax was also changed; I find _1 _2 a bit hard to read. I should note that I remember the other proposal about "it". I don't have a strong opinion against it. But I also don't feel particularly committed towards wanting to use it. The whole point of @1 @2 was actually to help in prototyping, e. g. to be faster when you write code initially. It's not a huge saving of time, admittedly so, but it does help, and I think in particular for IRB it can really be helpful (I'd wish we could still use _1 _2 and so forth together with real names of the variables; my use case was that I am fine with the initial block names, and I would keep them, but in the middle of writing more code, I just want to refer to the variable without necessarily always needing to remember the name. I have to scroll back with my crappy editor.) maedi wrote: > I see that $. is already a pre-defined variable which would > make $.method_name difficult to parse. All $-variables are quite hard to remember. With @1 or _1 this is a bit different because, like in a regex, you just refer to some specific group by number rather than a name. (Or just syntax, as is the case with the various $: $< and what not.) maedi wrote: > Though I still like _@. That one trips my brain up. I think we should be conservative about syntax. Perlisms can be useful due to begin succinct, but readability is also a useful metric to have. What surprised me the most is that people began to include _1 _2 and so forth in real production code. To me it is purely a method of testing and debugging aid; but I guess the moment you add functionality someone is going to use it, and a few of these change their style to include these. maedi wrote: > Another thing you could do which is very Ruby is provide a > special block param that acts as an object and interact > with that: I have no real problem with "it", even though I most likely won't use it. But we could use "it" also as reference object via [] method e. g. it[0], it[1] in addition to "normal" use of "it". adiel wrote: Over time I decided to always use a variable named x for such purposes: map.keys.select{|x| x =~ /foo/}. ---------------------------------------- Feature #18980: Re-reconsider numbered parameters: `it` as a default block parameter https://bugs.ruby-lang.org/issues/18980#change-101874 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal ---------------------------------------- ## Problem Numbered parameters (`_1`, `_2`, ...) look like unused local variables and I don't feel motivated to use them, even though I need this feature very often and always come up with `_1`. ```rb [1, 2, 3].each { puts _1 } ``` I have barely used it in the last 2~3 years because it looks like a compromised syntax. I even hesitate to use it on IRB. ### Why I don't use `_1` I'm not clever enough to remember the order of parameters. Therefore, when a block has multiple parameters, I'd always want to name those parameters because which is `_1` or `_2` is not immediately obvious. Thus I would use this feature only when a block takes a single argument, which is actually pretty common. If I use `_1`, it feels like there might be a second argument, and you might waste time to think about `_2`, even if `_2` doesn't exist, which is a cognitive overhead. If you use `it`, it kinda implies there's only a single argument, so you don't need to spend time remembering whether `_2` exists or not. It is important for me that there's no number in `it`. ## Proposal Hoping to introduce `it` as an alternative to `_1` later, experiment with warning `#it` method calls without any arguments or blocks. If nobody sees serious problems after some warning period, we'll implement `it` as follows: ### Specification ```rb [1, 2, 3].each { puts it } ``` `it`s behavior should be as close to `_1` as possible. `it` should treat array arguments in the same way as `_1`. `it` doesn't work in a block when an ordinary parameter is defined. `it` is implemented as a special case of `getlocal` insn, not a method. `it` without an argument is considered `_1` or a normal local variable if defined. `it` is considered a method call only when it has any positional/keyword/block arguments. ## Past discussions * [Feature #4475] default variable name for parameter: Proposed `it`, and merged as `@1`. * 2019/03/13: [DevelopersMeeting20190311Japan](https://docs.google.com/document/d/e/2PACX-… * 2019/04/17: [DevelopersMeeting20190417Japan](https://docs.google.com/document/d/1hw6Xca8… * 2019/04/20: [Ruby Committers vs the World](https://youtu.be/5eAXAUTtNYU?t=3118) * [Feature #15723] Reconsider numbered parameters: Renamed `@1` to `_1`. * 2019/08/29: [DevelopersMeeting20190829Japan](https://docs.google.com/document/d/1XypDO1c… * [Feature #15897] `it` as a default block parameter: Proposed `it`, and got closed because `_1` was merged. ### Compatibility `it` has not necessarily been rejected by Matz; he just said [it's difficult to keep compatibility](https://bugs.ruby-lang.org/issues/4475#note-6) and [`it` or `this` _could_ break existing code](https://bugs.ruby-lang.org/issues/15723#note-2). It feels like everybody thinks `it` is the most beautiful option but is not sure if `it` breaks compatibility. But, in reality, does `it`? The following cases have been discussed: * `it` method, most famously in RSpec: You almost always pass a positional and/or block argument to RSpec's `it`, so the conflict is avoided with my proposal. You virtually never use a completely naked `it` ([comment](https://bugs.ruby-lang.org/issues/15897#note-29)) * `it` local variable: With the specification in my proposal, the existing code can continue to work if we consider `it` as a local variable when defined. With the specification in my proposal, existing code seems to break if and only if you call a method `#it` without an argument. But it seems pretty rare (reminder: a block given to an RSpec test case is also an argument). It almost feels like people are too afraid of compatibility problems that barely exist or have not really thought about options to address them. Also, you could always experiment with just showing warnings, which doesn't break any compatibility. Even if it takes 2~3 years of a warning period, I'd be happy to use that in 3 years. ### Confusion We should separately discuss incompatible cases and "works but confusing" cases. Potential confusion points: * RSpec's `it "tests something" do ... end` vs `it` inside the `do ... end` * `it` could be a local variable or `_1`, depending on the situation My two cents: You'd rarely need to write `it` directly under RSpec's `it` block, and you would just name a block argument for that case. In a nested block under a test case, I don't think you'd feel `it` is RSpec's. When you use a local variable `it = 1`, you'd use the local variable in a very small scope or few lines because otherwise, it'd be very hard to figure out what the local variable has anyway. So you'd likely see the assignment `it = 1` near the use of the local variable and you could easily notice `it` is not `_1`. If not, such code would be confusing and fragile even without this feature. The same applies when `it` is a method/block argument. I believe it wouldn't be as confusing as some people think, and you can always choose to not use `it` in places where `it` is confusing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112422] [Ruby master Feature#17853] Add Thread#thread_id
by Eregon (Benoit Daloze) 14 Feb '23

14 Feb '23

Issue #17853 has been updated by Eregon (Benoit Daloze). FWIW, it seems the `Thread#inspect` change wasn't merged. ---------------------------------------- Feature #17853: Add Thread#thread_id https://bugs.ruby-lang.org/issues/17853#change-101870 * Author: komamitsu (Mitsunori Komatsu) * Status: Closed * Priority: Normal ---------------------------------------- # Abstract New method `Thread#thread_id` to get associated native thread id (LWP.) It might return `nil` if OS doesn't support thread id or equivalent. # Background When I tried to investigate which Ruby thread of an application is busy, I did the following steps - checked the CPU usage of the Ruby application's threads using `ps -eLf` or `top` (with H key) and got which thread is busy - dumped all the threads of the application using https://github.com/frsyuki/sigdump - tried to find a busy thread in the thread dump result, but the thread dump doesn't contain thread id... `Thread` class itself has no method to get associated thread id. If the class has `#thread_id` or something, I can create a PR on `sigdump` project to add `thread id` in thread dump output to make investigations with thread dump much easier. `Thread#name` may seem an alternative to `Thread#thread_id`, but `Thread#name` just returns a value that's set through `Thread#name=` while `Thread#thread_id` returns a thread id that OS or something has assigned. In case of Java, thread dump created by `jcmd ${pid} Thread.print` contains `nid` field which is an associated native thread id ``` "http-bio-80-exec-77" daemon prio=6 tid=0x0000000026f29000 nid=0xbd0 runnable [0x0000000020c7f000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:516) at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:501) at org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:167) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:946) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:315) - locked <0x00000007b16e3e88> (a org.apache.tomcat.util.net.SocketWrapper) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112368] [Ruby master Bug#19434] Fix YJIT compilation for Alpine Linux 3.17.2
by bkuhlmann (Brooke Kuhlmann) 14 Feb '23

14 Feb '23

Issue #19434 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Bug #19434: Fix YJIT compilation for Alpine Linux 3.17.2 https://bugs.ruby-lang.org/issues/19434 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Overview Hello. 👋 With the recent [Alpine Linux 3.17.2](https://www.alpinelinux.org/posts/Alpine-3.17.2-released.html) patch release -- which includes OpenSSL security patches -- I'm no longer able to build an Alpine Linux Docker image with YJIT enabled for Ruby. Prior to the 3.17.2 patch release, I could build Ruby + YJIT without issue. Here's the error I'm seeing when building locally: ``` #0 409.6 gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924 #0 409.6 Copyright (C) 2022 Free Software Foundation, Inc. #0 409.6 This is free software; see the source for copying conditions. There is NO #0 409.6 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. #0 409.6 #0 409.7 compiling ./main.c #0 409.7 compiling dmydln.c #0 409.7 compiling miniinit.c #0 409.7 compiling dmyext.c #0 410.1 making dummy probes.h #0 410.2 compiling ast.c #0 410.7 compiling bignum.c #0 410.8 compiling class.c #0 411.8 compiling compar.c #0 414.1 compiling compile.c #0 414.9 compiling complex.c #0 421.0 compiling cont.c #0 421.7 In file included from cont.c:38: #0 421.7 yjit.h:24:3: error: #error YJIT unsupported platform #0 421.7 24 | # error YJIT unsupported platform #0 421.7 | ^~~~~ ``` ...but what I see in the `yjit.h` source code is: ``` // We generate x86 assembly #if defined(_WIN32) ? defined(_M_AMD64) : defined(__x86_64__) // x86_64 platforms without mingw/msys or x64-mswin #else # error YJIT unsupported platform #endif ``` ...so AMD 64 should still be supported. ## Steps to Recreate Probably the simplest way to recreate this, locally, is to use my Docker project: 1. Run: `git clone https://github.com/bkuhlmann/docker-alpine-ruby` 1. Run: `cd docker-alpine-ruby` 1. Edit the top of the `Dockerfile` so it says: `FROM bkuhlmann/alpine-base:2.0.3` (this ensures Alpine Linux 3.17.2 is being used). 1. Run `docker build --platform linux/amd64 .` 1. Wait for the build to fail. ## Environment **macOS** `macOS 13.2` **Docker** ``` Client: Cloud integration: v1.0.29 Version: 20.10.22 API version: 1.41 Go version: go1.18.9 Git commit: 3a2c30b Built: Thu Dec 15 22:28:41 2022 OS/Arch: darwin/arm64 Context: default Experimental: true Server: Docker Desktop 4.16.2 (95914) Engine: Version: 20.10.22 API version: 1.41 (minimum version 1.12) Go version: go1.18.9 Git commit: 42c8b31 Built: Thu Dec 15 22:25:43 2022 OS/Arch: linux/arm64 Experimental: false containerd: Version: 1.6.14 GitCommit: 9ba4b250366a5ddde94bb7c9d1def331423aa323 runc: Version: 1.1.4 GitCommit: v1.1.4-0-g5fd4c4d docker-init: Version: 0.19.0 GitCommit: de40ad0 ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:111899] [Ruby master Misc#19353] Drop gcc <= 6 and clang <= 9
by shyouhei (Shyouhei Urabe) 13 Feb '23

13 Feb '23

Issue #19353 has been reported by shyouhei (Shyouhei Urabe). ---------------------------------------- Misc #19353: Drop gcc <= 6 and clang <= 9 https://bugs.ruby-lang.org/issues/19353 * Author: shyouhei (Shyouhei Urabe) * Status: Open * Priority: Normal ---------------------------------------- We test those old compilers using Ubuntu bionic. This OS is reaching its EOL. Making them available would become harder. I would like to drop supporting them. Any opinions? -- https://bugs.ruby-lang.org/

4 4

[ruby-core:112245] [Ruby master Bug#19421] Distribution documentation
by ioquatix (Samuel Williams) 13 Feb '23

13 Feb '23

Issue #19421 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19421: Distribution documentation https://bugs.ruby-lang.org/issues/19421 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I use Ruby a lot, on a lot of different systems, and help people and companies use it, including developers who install it on their systems. Over time, I found that installing Ruby isn't always easy. Part of this is due to package management. There are many systems, and Ruby has had some tricky migrations (e.g. OpenSSL is probably one of the most painful ones that lots of developers have trouble with). Arch Linux has been stuck on Ruby 3.0 for a long time, which could be considered surprising given that Arch Linux is often on the bleeding edge of releases. I personally use Arch too. So I decided to ask, what is holding them up from making a release? I found out they had many questions about how to distribute Ruby correctly. When I listened to those questions I felt that there are many ambiguities in how we build and package Ruby for operating system packages. This isn't to say that there isn't a good way to do it, just that we as a core team might be able to improve our communication about how Ruby is evolving and the implications for package managers (if any). I've introduced `doc/distribution.md` as an effort to start having better documentation for people distributing Ruby. There are many ways which people distribute Ruby, and many "partial" documentation or assumptions being made about how to distribute Ruby and I'd like to provide a convenient standard location that can help people build package for Ruby distribution. Ultimately this makes my job easier because the latest versions of Ruby will be easier to install, so that's what I care about, but I don't care about what specifically is in the document, except that I think we should listen to the kinds of questions being asked and, in the best interest of Ruby, provide guidance. There was a lot of good discussion on the PR, but my goal is not to make a finished document, but instead plant the seed so it can grow. https://github.com/ruby/ruby/pull/6856 Some follow up discussion is required: - What is the best practice for building source packages. The documentation I wrote from this was removed as "out of scope" but I disagree with that (https://github.com/ruby/ruby/commit/c35ebed895e1a3f7bced3db50ea0db8f284744e8) I don't have a strong opinion about what it should look like, but I think we should give a clear example of how to build source packages like what I wrote. - Related to the above, what is the official location for source tarballs? - What optional dependencies are required for building vs distributing Ruby. Arch Linux currently lists: `doxygen gdbm graphviz libffi libyaml openssl ttf-dejavu tk` as dependencies but it's not clear if this list is up to date, or what the expectations are. When someone installs Ruby (e.g. `apt-get install ruby`) what dependencies should be installed? I think it would be helpful to list expected dependencies (from a system package POV), etc. - Is Ruby needed for building Ruby? Should source packages install Ruby before building from source? If so, what versions are supported? - Clear guidance on gems that are distributed an alongside Ruby, and how security changes to gems are managed. Even if we have more detailed documentation elsewhere, let's summarise it and then cross-reference it. People who build packages to distribute and install Ruby should feel supported, they are very important to our community. To this end, I established `#distribution` channel on Slack for discussion. We should listen to the questions being asked and use those questions to drive improvements to documentation. -- https://bugs.ruby-lang.org/

10 20

[ruby-core:112394] [Ruby master Feature#19107] Allow trailing comma in method signature
by k0kubun (Takashi Kokubun) 13 Feb '23

13 Feb '23

Issue #19107 has been updated by k0kubun (Takashi Kokubun). I second this proposal. `def foo(bar:,)` doesn't seem like a real use-case, but when a method has so many arguments and I declare arguments in multiple lines, I would love to put a trailing comma to minimize future git diff and make reviewing the Ruby code easier. For example, this is today's `ERB#initialize`: ```rb def initialize(str, safe_level=NOT_GIVEN, legacy_trim_mode=NOT_GIVEN, legacy_eoutvar=NOT_GIVEN, trim_mode: nil, eoutvar: '_erbout') # ... end ``` This line is still short enough to fit on my screen, however, if we were to add another option, e.g. `filename`, I would write: ```rb def initialize( str, safe_level=NOT_GIVEN, legacy_trim_mode=NOT_GIVEN, legacy_eoutvar=NOT_GIVEN, trim_mode: nil, eoutvar: '_erbout', filename: nil, ) # ... end ``` which doesn't seem awkward to me. But this is a SyntaxError today. If you don't put a `,` there, you'll see a diff on `filename` when you add another option after that even if the patch is not related to `filename`, which would make me frustrated when reviewing that code. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-101836 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112393] [Ruby master Feature#19107] Allow trailing comma in method signature
by rubyFeedback (robert heiler) 13 Feb '23

13 Feb '23

Issue #19107 has been updated by rubyFeedback (robert heiler). To me the ',' there looks rather awkward. Then again the first time I saw def(foo:) I was also confused. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-101835 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0