Debugging: Change suggested Ruby extension to Ruby-LSP and more

[scheals]

Checks

• This is not a duplicate of an existing issue (please have a look through our open issues list to make sure)
• I have thoroughly read and understand The Odin Project Contributing Guide
• Would you like to work on this issue?

Describe your suggestion

Main issue

The Ruby extension the curriculum links to has been deprecated for a while. VSCode users are now told to use the Ruby LSP extension by Shopify instead. Plenty has changed in terms of features (some lost which are WIP, some gained) and the way you interact with the extension - it more or less expects you to use Bundler and declare the Ruby version you're using. Until Shopify/vscode-ruby-lsp#945 gets released, not having a Gemfile.lock in a workspace is going to prevent Ruby-LSP from starting up - this might be important if users try debugging using Ruby-LSP instead of the rdbg extension since that'll fail somewhat enigmatically and some features will be unavailable.

Additional considerations

Now, to be fully thorough, a bit in Object Oriented Programming about setting up Rubocop with the old extension would need to be changed as well. Issue is, the new extension needs a Gemfile with Rubocop (and whatever addons like rubocop-rspec) in it and learners were not taught how to use Bundler at all - in fact, they never will be. In addition to that, from my short and basic experience, it seems like Rubocop + extension behaviour changes depending on the presence of .ruby-version or .rubocop.yml - not sure how the mechanism works but it tries to guess what the right version of Ruby is being targetted. It might be prudent to consider creating a new lesson covering Ruby project structure, Bundler, config files for Rubocop/inline Rubocop rule disabling, setting .ruby-version with rbenv.

Another part of thoroughness would potentially be setting up a Gemfile and a .ruby-version for the Ruby Exercises repo. Currently, it is making use of a globally installed rspec and the instructions make the learners go to a particular directory so the tests run as they should, for ex. cd 1_data_types and then rspec spec/numbers_exercises_spec.rb. A per exercise directory Gemfile/.ruby-version might be needed because of that OR custom Ruby-LSP config for multiroot workspaces.

Proposed fixes

1. Change only the bit in Debugging lesson without providing the temporary workaround when lacking a Gemfile.lock since it should be fixed soon-ish.
   Potential drawbacks: The fix doesn't come fast enough and folks have issues for even longer of a time. Rubocop in OOP is not addressed. The message learners get from Ruby-LSP after fix is applied might still be enigmatic enough to them so that issue persists.
2. Like 1., but provide the temporary workaround.
   Potential drawbacks: Have to remove the workaround after the issue is fixed upstream. Rubocop and message from Ruby-LSP issue from 1. still applies.
3. Change the Rubocop in Object Oriented Programming with just telling learners that they need to run bundle init then bundle add rubocop and rbenv local <current_ruby_version_TOP_uses> in every project root. Together with:
   a) 1. or,
   b) 2.
   Potential drawbacks: This won't be enough of an explanation and might just confuse users OR set them on a bad path of just copy-pasting their config files. Drawbacks of 1./2. apply without the Rubocop bit.
4. Create a new lesson following OOP lesson on Ruby project structure, .ruby-version, rubocop.yaml, Bundler, moving the Rubocop bit from Object Oriented Programming to it. Together with:
   a) 1. or,
   b) 2.
   Potential drawbacks: Will take the most amount of time. OOP lesson has already been a pain point due to its length and complexity - perhaps adding another lesson without real practice might exacerbate that. Drawbacks of 1./2. only apply insofar Gemfile.lock issue is concerned.

Path

Ruby / Rails

Lesson Url

https://www.theodinproject.com/lessons/ruby-debugging

(Optional) Discord Name

No response

(Optional) Additional Comments

No response

[JoshDevHub]

Thanks for making this @scheals 🙌

My own preference is probably option 4. I think using bundler makes the most sense, and at this point in the curriculum (ie. before the Tic-Tac-Toe project), I also think we can't rely on learners to acquire knowledge around this "by osmosis" -- which has been the approach regarding bundler.

I also think it's just nice to get learners using this stuff the way professionals do. Feels in-line with the TOP ethos.

I'm not sure how I feel about rubocop configuration stuff making it into this lesson. That might work better as a dedicated, separate thing? But I do like going into bundle init, what are Gemfile and Gemfile.lock, how do you add and install project dependencies, running commands with bundle exec, etc.

Going to tag @TheOdinProject/ruby team to solicit more opinions.

[JoshDevHub]

Alright after talking to the team some, we're onboard with option 4 (so a full lesson on bundler and related things). Would you want to take on writing a lesson for that content @scheals ? No pressure or anything if you don't have the time, but you're absolutely welcome to make that contribution if you want.

[scheals]

I am thinking about using ES6 Modules as a blueprint for this lesson, using Lesson overview as a base, specifically touching on:

• Explain what npm is - > what bundler is
• Describe what npm init does and what package.json is. -> what bundle init does and what Gemfile is
• Briefly explain what a development dependency is
• Explain one of the main benefits of writing code in modules -> separate Ruby files that you include somewhere else are not called modules, right? I guess I'd explain the usual project structure here and explain why breaking down stuff into separate files based on class/module is the way to go since that seems to be the idea in JS as well
• Explain “named” exports and “default” exports. -> I don't think Ruby has these partial exports/imports, it's just require that takes the entire thing, right?

If we want to include some stuff on Rubocop, then I can work off Chook's plan and JS' Linting. I guess it is a little "simpler" here 'cause Rubocop is both a linter and a formatter. Guess we could throw the template repository bit in there too then since all the repos will need a Gemfile with Rubocop and a .ruby-version (and potentially rubocop.yml). So I'd add the Lesson overview bullet points into that lesson:

• Set up a linter and formatter to make your code better.
• Learn what template repositories are and how to set one up.

I won't lie, my knowledge of this stuff is rather basic aka enough to know how to use it and troubleshoot the basics so I'll appreciate eyes on this throughout my work 😆

[JoshDevHub]

Using the ES6 Module lesson as a base sounds like a great idea to me.

For separate files, you have it right. I think it's a good opportunity to discuss project structure and the benefits of breaking things down into separate files.

For exports/imports, you're correct that Ruby just has its require mechanics. There are a couple of things around that you probably want to touch on that are unlike JavaScript's systems:

1. require vs. require_relative. What's the difference and what situations should you use each. If you don't know, the common convention is to use require_relative when requiring code internal to your own project and require when using a gem.
2. While researching, you'll probably come across fancier things like autoload. While undeniably useful in certain situations, I'd probably just avoid going into it. It's not going to be important for our learners in the ruby course and everything can be done with require and require_relative.
3. You can maybe talk about the rules around what's "transmitted" across files. Like let's say you have a file named a.rb and it has the line a = 5. If another file requires a.rb and tries to use a, there will be an error. Local variables are still not in scope for the file that's doing the requiring.

Other than that, I think everything you have sounds great.

I think we might plan to have a new, small section called "Ruby Tooling" or something, and it'll have this and a lesson on rubocop using Chook's outline. This would give us adequate space to explore this stuff and it would decouple these things from the OOP content. Might even think about moving it earlier in the course than the OOP section.

If you're good with taking on the bundler lesson, I think I'll tackle the rubocop content. Sound good to you?

Definitely feel free to ask any questions you have. And also you're very welcome to use the "draft PR" feature if you ever want maintainer feedback on in-progress work.

[scheals]

If you're good with taking on the bundler lesson, I think I'll tackle the rubocop content. Sound good to you?

Sounds good to me. Thanks for the pointers and I'll do draft PR for sure when the time comes :D

[scheals]

I'm working on it ever so slowly, they've fixed the issue with it not starting without Gemfile.lock and not communicating anything, so now we need to deal with the dialog that pops up - we've got an example of confusion relating to this already.

[scheals]

@JoshDevHub I'm having an issue figuring out whether I want to introduce the concepts theoretically by describing them or introduce them while hand-holding the learner through upgrading their Bubble Sort project's structure. You can see what steps I want to take by going through the commits in this branch of my project. The idea is that whenever the concepts would be applicable, they'd be introduced.

[sean-garwood]

Thanks so much for writing this, Scheals! Certainly would have been helpful to have a quick explanation of Gemfiles, dependencies, environment (and associated vars), and the Ruby -> Ruby-LSP extension change in VSCode earlier in the course (though the latter was ~1.5 months ago, so can't adjust for that).

Just a user here, but this confounded me for a long time, and it messed with my BST project to the point that it was distracting--and that particular project was hard enough as it was! I spent a couple hours googling around, trying to find the order of operations for bundler (e.g. "Do I have to write a Gemfile from scratch?", "I already installed these gems, what gives?") and how that ties in with rbenv and $LOAD_PATH. Learned a lot on the way, but the thing I love about this course is the pedagogy: higher-level explanation (body of lesson text) -> reading assignment -> exercise/small project -> ... -> large project. Having a quick lesson on this would have been just the thing, because then the student at least knows that bundle and Gemfile/.lock are "things."

[github-actions]

This issue is stale because it has had no activity for the last 30 days.