Place gems under ~/.local/share/rv/gems/ if the dir under ~/.gem/ is not present. - #231

Codecov Report

❌ Patch coverage is 0% with 14 lines in your changes missing coverage. Please review.

📢 Thoughts on this report? Let us know!

@indirect: Two things:

• I went with ~/.local/share/rv/gems/ruby/VERSION to match ~/.gem/ruby/VERSION. Let me know if you would rather have ~/.local/share/rv/gems/ruby-VERSION per rv ruby run overwrites GEM_HOME / creates a dot dir under ~ #226 (comment)
• Since the calculation looks under ~/.gem, this means the test is non-deterministic based on whether ~/.gem/ruby/3.3.5 exists. Any thoughts on how to best handle this? I don't think the test should write into the home dir, so my two thoughts are:
  • Change $HOME to a unique temporary dir for at least this test, and then test both the legacy and XDG-compatible paths. Note that placing this under /tmp/ is not safe for this on macOS. 😕
  • Add a level indirection to the .exists(…) call so that the value can be mocked for testing.

• Change $HOME to a unique temporary dir for at least this test, and then test both the legacy and XDG-compatible paths. Note that placing this under /tmp/ is not safe for this on macOS. 😕

Okay, I think I figured out an idiomatic way to do this: c8ce7a6

The tests are already performing string replacement to normalize the temp dir, so it wasn't too much of a stretch to extend this to a unique temp dir.

I have no idea what the code coverage tool is on about. This PR adds a bit of implementation code, and all new/changed code is tested. It shows coverage of these lines going down, which sounds bogus to me.

I had the same issue yesterday with #229. I wonder if it's related to integration tests not properly recording coverage? I recall similar issues in Ruby with getting integration tests to record coverage when covered code would run in a subprocess. Not sure if our integration tests do that, but just mentioning it as an idea.

Ohh, right, @adamchalmers was telling me about this a few days ago I think—the tests that shell out to rv don't record coverage right now, we still need to switch the tests to running rv subcommands in-process to get accurate coverage reports for those.

I'll try dedicate some time into improving code coverage so it's actually accurate, because the issue seems to be coming up in most PRs.