Project

General

Profile

Actions

Bug #19414

closed

uninitialized constant URI::WSS in 3.0.X and 3.1.X

Added by noraj (Alexandre ZANNI) about 1 year ago. Updated about 1 year ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:112218]

Description

I have a library called ctf-party, making use of URI:WSS, and it's making my CI pipeline fails.

I'm able to reproduce it locally (bundle exec rake test), working with ruby 3.2.0 and not with 3.1.3.

The error is:

irb(main):001:0> require 'uri'
=> true
irb(main):002:0> URI::WS
=> URI::WS
irb(main):003:0> URI::WSS
(irb):3:in `<main>': uninitialized constant URI::WSS (NameError)
        from /home/noraj/.asdf/installs/ruby/3.1.3/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>'
        from /home/noraj/.asdf/installs/ruby/3.1.3/bin/irb:25:in `load'
        from /home/noraj/.asdf/installs/ruby/3.1.3/bin/irb:25:in `<main>'

I don't understand why is that happening since it exists in the official documentation and the code looks ok to me on tag 3.1.3 which is strictly identical to the code on tag 3.2.0.

It works if I require the file explicitly:

irb(main):004:0> require 'uri/wss'
=> true
irb(main):005:0> URI::WSS
=> URI::WSS

The issue come from the fact that in 3.2.0 'uri/wss' is required but not in 3.1.3. In 3.0.5 it is even worse as neither ws and wss are required.

Updated by jeremyevans0 (Jeremy Evans) about 1 year ago

  • Status changed from Open to Closed
  • Backport changed from 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN to 2.7: UNKNOWN, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONTNEED

Since this is fixed in the master branch and Ruby 3.2, this is a backport request for 3.1 and 3.0.

For 3.1, it needs c94f964e3f94e9f934a3f4e73fb55f5fd2a21f08

For 3.0, it needs c94f964e3f94e9f934a3f4e73fb55f5fd2a21f08 and b875a85c5367b9dff96e1ca1e78a2e35580a2f80

Updated by noraj (Alexandre ZANNI) about 1 year ago

jeremyevans0 (Jeremy Evans) wrote in #note-1:

Since this is fixed in the master branch and Ruby 3.2, this is a backport request for 3.1 and 3.0.

For 3.1, it needs c94f964e3f94e9f934a3f4e73fb55f5fd2a21f08

For 3.0, it needs c94f964e3f94e9f934a3f4e73fb55f5fd2a21f08 and b875a85c5367b9dff96e1ca1e78a2e35580a2f80

Do I have something to do? Thanks to the Backport field this issue is listed in Backport 3.1 and Backport 3.0 but has status closed. However, I don't see the backport committed on ruby_3_0 or ruby_3_1.

Updated by duerst (Martin Dürst) about 1 year ago

@noraj (Alexandre ZANNI) This is just how backporting works. Closed means closed on trunk; the backporting maintainers check what they need to do separately.

Updated by noraj (Alexandre ZANNI) about 1 year ago

duerst (Martin Dürst) wrote in #note-3:

@noraj (Alexandre ZANNI) This is just how backporting works. Closed means closed on trunk; the backporting maintainers check what they need to do separately.

Ok, thank you and sorry for the naive question. I read HowToBackport but was not sure what to do next.

Updated by nagachika (Tomoyuki Chikanaga) about 1 year ago

  • Backport changed from 2.7: UNKNOWN, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONTNEED to 2.7: UNKNOWN, 3.0: REQUIRED, 3.1: DONE, 3.2: DONTNEED

Merged PR into ruby_3_1 at da27583cf364c0d69c085db4abf358c334a8eca1.

Actions

Also available in: Atom PDF

Like0
Like1Like0Like0Like0Like1Like0