Closed bitboxer closed 10 years ago
Sorry :blush: I use RVM, so I didn't write it ;) But I will of course add it, if you write it :smile:
I will do that as soon as you finished adding setup and the other methods to your other classes. After that I follow your lead and implement everything in the same manner.
Excellent! I will finish add support for setup and the other new methods during this weekend. There's also another feature brewing in the labs :wink: Keep your eyes on the sky!
Just wanted to share some thoughts on the topic of "Ruby Managers": According to some polls (Ruby Rogues and another one I don't remember) I've seen over the last few month, the ranking according to popularity for version managers is as follows:
Opposed to RVM, rbenv and chruby don't come with a build tool. I think rbenv is mostly used in combination with ruby-build, also bei sstephenson. But chruby is also an interesting candidate: Both ruby-version and rbfu were deprecated, because "chruby is the better solution". The author postmodern
also released ruby-install, which is possibly used mostly alongside chruby equivalent to ruby-build for rbenv.
The questions are:
(For RVM those questions are trivial to answer, because its a egoistic and monolithic monster with its own installer and build tool)
I think it does not make sense to use rbenv without ruby build. I would install both at the same time. And I am not sure if i want to use homebrew for that.
Ok, understood :smile:
Just seeing this again :smile: . Have we decided which way to go from here? I will have spare time on wednesday to focus on all the smaller opensource things on my todo list.
See #17
The rbenv module needs some work by the user afterwards to add the rbenv bin dir to the path. How should I deal with that? Is there a default way to display messages like these?
We didn’t have a situation like that before :wink:
I don’t yet understand why we need a message. Shouldn't that be part of the .zshrc anyways?
Yes, it should be part of zshrc. I will ignore this and let the user deal with it.
Yep :smile: Exogenesis users should still take a good luck at all components of their dotfiles. Exogenesis should only make the boring parts easier (and a little more enjoyable :wink:).
We could put into the manual though :smiley_cat:
Hm..another problem: you don't mention the patch level in your packages.yml
. I have to specify it in rbenv, it won't let me install ruby versions without it. This leads to the problem that the update method can't know when to update to the next patch level of MRI. I could scan through all versions and pick the best one. Sadly the rubies don't have a consistent versioning theme. Or do you know a gem that knows this for all rubies?
Really? What the hell rbenv?
Not sure if I want to adjust my packages.yml for every patchlevel release :unamused: It also is kind of bad, because if I run rake update
I want to upgrade all my Rubies – which is not possible if I give a patch level…
What is your current (manual) way of upgrading your Ruby? You see that there is a new ruby patch and then you install the version with patch level?
I thought that all rubies have a patch level scheme were the higher the number the newer the version (within one version). Is that not true?
Rbenv has a very strict version policy. They don't want you to end up with a wrong version that is not compatible with your code. Because of that you have to specify exactly what version you want. And I am not sure if I want to write a parser that is able to parse all nuances in Version Numbers of all the different Ruby VMs
Hm… Ok, so then there’s only one way to do it:
The rubies
in packages.yml have an optional patchlevel. If you are using rbenv then you need that patch level. If you are on ruby-install or RVM, you don’t need it (but you can of course provide it, because both accept that optionally). Ok?
Okay. Sounds reasonable
Why no rbenv :sob: ... I will fix that in the next week! With proper setup and teardown