Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve .irbrc's loading behaviour #674

Closed
st0012 opened this issue Aug 9, 2023 · 4 comments · Fixed by #901
Closed

Improve .irbrc's loading behaviour #674

st0012 opened this issue Aug 9, 2023 · 4 comments · Fixed by #901
Labels
enhancement New feature or request rubyconf-hackdays

Comments

@st0012
Copy link
Member

st0012 commented Aug 9, 2023

I noticed 2 "surprising" .irbrc loading behaviour recently:

Lack of hierarchy on rc file loading

Unlike many other tools that have "project level" and "user level" configurations, IRB only accepts a single .irbrc file through a fixed loading order.

For example, it doesn't load project/.irbrc if ~/.irbrc is present.

This is unintuitive to most users as popular tools like Pry or VS Code both have "user level" and "project level" configurations. And they usually load "user level" configs first, and allow "project level" configs to override them.

$ pry        
~/.pryrc loaded
project/.pryrc loaded
[1] pry(main)> 

.irb_history is always placed at the same place as .irbrc is defined

This is also not an intuitive design. Most of the time, .irb_history should not be inside the project folder. So the current reality is, if a project wants to define .irbrc for all its developers, .irb_history needs to be added to .gitignore or the project needs to configure IRB.conf[:HISTORY_FILE] (example).

@ktopolski
Copy link

Hello 👋

First time irb contributor here - just wanted to say thank you for maintaining Ruby's core tool! 🙏

I'd love to contribute to give back to the community so I picked first part of the issue and made a PR. I feel like I'm walking in the dark a bit, but managed to test it on the "local"(github codespace) environment and it passes automatic tests as well. I wasn't able to verify the yamatanooroti due to codespace limitations - might get back to it on local environment next week.

I'm extremely open to feedback - would love to contribute more to irb in the future!

@elfham
Copy link

elfham commented Mar 13, 2024

Since #859, ~/.config/irb/irbrc is loaded twice when $XDG_CONFIG_HOME is set.

% irb
irb(main):001> IRB.rc_files.select { |rc| File.exist?(rc) }
=> []
irb(main):002> exit
% echo "puts __FILE__" > ~/.config/irb/irbrc
% irb
/home/elfham/.config/irb/irbrc
irb(main):001> IRB.rc_files.select { |rc| File.exist?(rc) }
=> ["/home/elfham/.config/irb/irbrc"]
irb(main):002> exit
% export XDG_CONFIG_HOME=~/.config
% irb
/home/elfham/.config/irb/irbrc
/home/elfham/.config/irb/irbrc
irb(main):001> IRB.rc_files.select { |rc| File.exist?(rc) }
=> ["/home/elfham/.config/irb/irbrc", "/home/elfham/.config/irb/irbrc"]
irb(main):002> exit
% 

IMHO, only one irbrc file should be loaded at each "user level" and "project level".

For example, if there are 4 files as below,

  • user level
    • ~/.config/irb/irbrc
    • ~/.irbrc
  • project level
    • ./.irbrc
    • ./_irbrc

only ~/.config/irb/irbrc and ./.irbrc should be loaded and others should be ignored.

How do you think about this?

@elfham
Copy link

elfham commented Mar 13, 2024

By the way, since #859, ~/.irbrc is loaded twice at ~/ if HOME directory is symlinked.

% LANG=C ls -l /home/elfham
lrwxr-xr-x  1 root wheel 23 Jan 20  2014 /home/elfham@ -> /mnt/nfs/home/elfham
% echo "puts __FILE__" > ~/.irbrc
% cd ~/
% irb
/home/elfham/.irbrc
/mnt/nfs/home/elfham/.irbrc
irb(main):001> exit
% 

@ktopolski
Copy link

Hey @elfham 👋

Sorry so much for disappearing so suddenly! I really hoped to finish this one and then life took an unexpected turn - deeply sorry about that. Also thank you to @hahmed & @tompng for working on this one 🙏

I hope I'll be able to make up for this one as I'll have more time for OSS soon🤞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request rubyconf-hackdays
Development

Successfully merging a pull request may close this issue.

3 participants