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

Already on GitHub? Sign in to your account

dk.rb install needed when installing new ruby release on top of the preceeding one #151

Closed
badal opened this Issue Feb 24, 2013 · 5 comments

Comments

Projects
None yet
4 participants

badal commented Feb 24, 2013

I am on Windows 7 64 bits.
I install each new ruby release in the same directory C:\ruby193, on top of the preceeding one. For the DevKit to work, I have to run 'dk,rb install' (just that).
_md

Owner

Azolo commented Feb 24, 2013

Yeah, currently dk.rb install actually changes the files in a Ruby installation to point to the Devkit. So even though the configuration isn't changing, since your Ruby installation changed you have to run the dk.rb install to change your new Ruby install.

I think @luislavena was working on something to fix that, but I may be speaking out of turn. In theory it is possible to gemify the Devkit and specifically the way it loads, but last time I tried I didn't have the programming chops or overall patience to do it.

Currently though, it is working as designed.

@Azolo Azolo closed this Feb 24, 2013

@luislavena luislavena reopened this Feb 24, 2013

Owner

luislavena commented Feb 24, 2013

@Azolo actually what the user is reporting is that doing an upgrade of Ruby requires reinstall the devkit again.

There is a simple way to avoid that in the installer for operating_system.rb to avoid replacement.

Of course, in the long run, a more robust solution should be put in place.

I'm reopening this as I asked the user to report it here 😉

Contributor

voxik commented Feb 24, 2013

Actually, we could improve the situation a bit. There are several possible ways which comes to my mind

  1. Place the content of unless gem_installer.spec.extensions.empty? into some common location, such as users home directory and try to require this file. So the dk.rb install would create this file, instead of modification of operating_system.rb
  2. We could introduced some environment variable, such as DEVKIT_PATH, which would be appended to the ENV['PATH'] inside of unless gem_installer.spec.extensions.empty?

The downside of these approaches would be, that every Ruby would need to use the same DevKit. Not sure if that is problem, however it could be probably implemented in a way that also the current possibility of modification to operating_system.rb would be preserved. User would choose his preferred way.

Owner

Azolo commented Feb 24, 2013

@luislavena Ahh, I see. I have an idea then.

@Azolo Azolo closed this in 688b690 Feb 24, 2013

Owner

Azolo commented Feb 24, 2013

Alright, that should fix the problem. But we should still talk about a more robust solution.

@voxik I was thinking more like a vendored gem that handled all of that. Then place a .devkit folder or something in the home directory that could store multiple Devkits itself, or configurations pointing to existing/alternatively-installed Devkits.

That way you could vendor it with an install and have it look for the Devkit information. Then we could also store information about the Devkit that was used to compile Ruby and if a Devkit installation matches use it otherwise throw up an error message and offer an easy command to download and install it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment