The Changelog: Software Development, Open Source - RVM and Ruby Version Managment (Interview)

Episode Date: September 6, 2013

Adam Stacoviak and Jerod Santo talk with Michal Papis about the history and future of RVM, the plan for RVM 2.0, the complexities of managing your Ruby version, Ruby 2.0 and more.

Welcome back, everyone. This is The Change Log, where our members support a blog and podcast that covers what's fresh and what's new in open source. You can check out the blog at thechangelog.com, our past shows at 5by5.tv slash changelog. And something new, you can subscribe to The Change Log Weekly, our weekly email covering everything that hits our radar in open source you can subscribe at the changelog.com slash weekly this show is hosted by myself and our co-host today uh our managing editor as a matter of fact is jared santo jared say hello hey how you doing good to have you on the show my friend yeah it's uh yeah i think the last time you were on the show was the the very first live show roundup when we kind of came back from our hiatus yeah that's right that

was a fun show that was a fun show we have to do more of those so if you're a fan of that show give us a shout on twitter we like that but uh this is episode number 102 102 and we're joined by michael papis he's the maintainer of rvm and he's also the release manager for RVM at Engine Arts. So, Michael, welcome to the show, my friend. Hello, everybody from Poland. You are from, yeah, you're from Poland, aren't you? How do you pronounce your city name? Oh, no, it's Gorzów, but it's really a small city,

so it's more close to Berlin if anybody looks on the map. Gotcha. Yeah, I did look on the map. I was like, where is he at? Because us Westerners here in the US, we tend to be oblivious to this thing called a map. And we sometimes forget our geography and you have to look it up. I mean even Poland. You know my last name, right?

My last name is Dekowiak. And so my grandfather and a lot of my lineage comes from that area, so you'd think I'd be a bit more familiar. And if you asked me if I speak Russian or Poland, I'd say no. It's quite easy. Before we kick off the show, I want to give a shout out to our sponsor, AppSketchBook. If you do any sort of app design, which I imagine a lot of our audience does, I don't know about you, but whenever I have an idea, I have to get it on paper before it comes to life. And that's exactly what AppSketchBook lets you do. They make sketchbooks for designers and developers so you can get your interface ideas onto paper before actually designing your next

idea they're available in ux responsive iphone and ipad blueprints they're on every page so if you're designing an iphone app obviously you want to kind of sketch against that or even collaborate with one of your designers to kind of get some of your ideas out you can go to app sketchbook.com the coupon code to use is DANSENTME. That's DANSENTME to get $5 off your next order. This will be in the show notes, so head to 5by5.tv slash changelog slash 102, which is this episode number, to learn more and click through to appsketchbook.com.

But let's learn a bit more about Michael. So, Michael, you took over, I guess, the helm of RVM not long ago, about almost two years ago, I bet now. Yeah. So it's almost two and a half years since I started contributing to RVM. And I guess my first bigger time with RVM was during summer when Wayne went for vacation with kids and needed some time off. And I proposed to do the maintenance and keeping users up to date with everything what's going on. So yeah, it's two years now.

What was your experience, I guess, before that time period? What got you into even hacking or even making some suggestions to Wayne, the creator and original maintainer of RVM? Yeah, so I needed RVM for my work. I was installing servers, and it was really a pain. And I tried RVM and it was quite easy. But I found some patches were missing for Ruby Enterprise Edition or Ruby 187. I don't remember exactly, but it was the old one. So I've added the patches and that was my first contribution and from that i really fast started to contribute to rvm and few months it

was like march and during the summer july i already was contributing almost full time nice how mature was it at that point was it at 1.0 back then already? I've started at 1.2 and when the summer it was like 1.5, 1.6. 1.6, yes. It was 1.6 during the summer so i have become real-time contributor during the one six you mentioned you were doing it for your work where and i think before the call actually kicked off before we actually started recording uh you kind of mentioned that it was you're starting to work with rvm and maintaining it i'm not sure if that coincided exactly the same time you started engineering is that who you were working with and why you needed to kind of hit the lower levels and kind of hit these breakpoints at patch levels?

And as you mentioned, Ruby Enterprise Edition. So I was needing RVM for my work, and I really liked the code and what it does. So it was something I always wanted to do, do some open source, contribute, make people happy. And during my work time and my free time, I started to contribute a lot. And I basically spent almost all my free time contributing to RVM. And at one point, i got really tired of my day job so i found a chance with wayne to do some small wayne the original author of rvm i found some some more time to do projects with wayne and i quit my job to take care of RVM and to do the smaller projects,

which allowed me to work even more on RVM. Wow. So when you said you quit your job, were you being compensated by RVM? Because I know that RVM's had a pledge on their homepage for a while, and I think they've maybe raised $20,000-ish, which probably doesn't pay the bills, but were you unemployed getting paid? What was the scenario there? Yes, so at this time it was a lot of contributions thanks to Ryan Bates, who started Action Let's Show Wayne some appreciation for RBM because of the bad comments from RBM. And thanks to the contributions, Wayne had quite good funding for a short time, which allowed him to fund me to do the job for minimal money.

But it was really something refreshing for me to just quit all the standard tasks and do the good job to the community. So that's interesting. i didn't know so besides ryan who else was uh was ryan the main benefactor of some of that injection or was it others no so actually it's it wasn't just ryan he he only started the action he he just asked on twitter to contribute I see. Gotcha. Maybe if that comes into play in this conversation, you want to speak to some of that time frame? Sure. I mean I wasn't too close to it. I read some of the blog posts, but I wasn't – I'm sure Michael was intimately involved in that situation.

And mostly I was aware of it because as an RVM user – and by the way, thank you for all the work you've done. I'm a longtime RVM user, and it saved me a lot of time in my work. But I felt the pain of RVM basically overriding the CD function in your shell personally because I also override the CD function in my shell. But my solution was to simply just modify my own monkey patch to just work with RBM's monkey patches and just keep on working. But I think that type of thing was what originally spawned the writing of RBM and then these other tools. And I'm not sure of all the drama that happened but there was many blog posts i'm sure there were many tweets and you know uh maybe michael can speak to it a little bit more but i think it got personal at a certain point unfortunately and great glad to hear that

out of all that came actually this funding and these people supporting the project which had allowed you to move in and do the work you've been able to do. Yeah, it was touching us personally and Wayne. For a short time, we felt really bad, but it passes with time. You can see good points. It ended up really good for users. So we got new functions, new options to run RVM, and we have new files, so you don't need to use RVM-RC. You can use Ruby version, which is now a common file for major tools that do the switching now.

Yeah, I think it's become commonplace to see a Ruby version file more so than you see an RVM RC file. I never use RBM, but do they have a special file that they kind of watch for to switch the Ruby? So they finally switched in some time to Ruby version, but for a long time they used RBM version. Gotcha. And in fact now, I mean, you can put the Ruby version right in your gem file now, correct, with newer versions of Bundler, and RBM will recognize that as well to switch to that Ruby? Yes, yes. First we had implemented, before Bundler implemented the Ruby directive,

we got a comment support, so you could write it in comment, and later on Bundler introduced the Ruby directive. And we still support the command because in the Ruby directive, you can write any Ruby code. So you can do some magic to load Ruby version file in this place. And to avoid any problems with reading Ruby from shellcode because all the tools are shellcode,

we just allow the comment, which is just a string, which is Ruby version. So if you have something else than a string in the Ruby directive, you can use comment to overwrite it for RVM. So now you guys are pretty much supporting four different ways just over time huh so you can get that done do you still support the rvm rc i'm sure you do at least in version one yes so so in version one it's still the number one format that is red so if you have Ruby version and RVMRC, then RVMRC will be read. And there is no problem with some magic versions interpreted by other tools, which would be not recognized in RVM

because you can add extra logic in RVMRC. So what's the preferred way going forward is it to use the gem file or to use the Ruby version file so if you just want to use Ruby and nothing else then Ruby version is great

but during the initial discussion for Ruby version which was introduced by Fletcher Nicole I proposed initial discussion for Ruby version, which was introduced by Fletcher Nicole, I propose another format which allows you a list of settings, something key equals value,

where you can set Ruby equals 193, and you can set Java equals 17. I don't know Java version so good. so you can specify more than just ruby version you can describe your project because you you never depend on just ruby you always use something else and and more you use database so you might want to specify which database to use, which Python version, which JavaScript version. And for that, I would see the future of switching environment. Just one file, versions.conf, in which you can set everything, not just Ruby version, because Ruby version was really convenient

just for Ruby when we had tools to switch Ruby version. But for the future, what we will end up, it's one file configuring everything in your project. I like that. So it's kind of like a middle ground between executing arbitrary shell commands and simply specifying a Ruby version. It allows you to specify versions

for all the different dependencies you have. Yes, yes. That's the plan. And that file is already supported, but because in Rvm1 we switch only Ruby versions, it only allows you to switch Ruby versions. You can write anything inside, but you would need other tools to read

it. In RVM 2, we plan to introduce support for switching almost everything. We want to introduce support from other tools like virtualenv. I think it's virtualenv for Python.

NVM for Node.js. So everything else that's already working on the market, we want in the end, it merge in one tool that will be able to switch. So you don't need 10 tools to switch your environment. Just one tool and it's ready. It seems like from app to app or project to project, it's going to really get diverse. So probably managing this gets tougher over time. And that's where pull requests and issues on GitHub really come into play to help you keep a heartbeat on what's new out there,

what's different for someone else, and be able to report that back and whatnot. Can you talk a bit about what it's like to take over a project like this? I know that you'd mentioned it's been almost two and a half years now since you started, and we kind of talked a little bit about the intros of this where it kind of spawned from some of the drama but also turned into some financial injection through donations to to rvm and wayne being able to being able to bring you on board full-time and you being in a place in your life to be able to take it on but what's it like taking over a project like rvm so from the

standpoint that it's really important to the developers that use it like it becomes the center point at which they pivot what is it like taking over a project like that? So you don't really get to think about it. When you start to do something and you get passionate about it, you just do the work. And because it's used by almost everybody, you get so many tickets all the time that you don't have time to think so you just do the tickets do the tickets do the tickets and right now sometimes i get moments

because everything it's fixed i get the moments like three days of silence so i don't have any tickets but then I get 10 tickets again and working on it so I planned RVM 2 for over a year now but every time I'm thinking it's ready I can start working on it everything is finished for RVM 1

and then I get 10 new tickets and spend 3 next days working on the tickets and helping people to solve their problems and fixing the small things. And every time it's something smaller and smaller, but people find these things with the quality when it increases overall. Then in the end, people start complaining about smaller and smaller things to make it fine-tuned for everything they need.

I see on your RVM 2.0 plan, you got a couple other contributors mentioned. Are they involved at all in helping kind of manage the influx of tickets or kind of doing some pre-validations i know like at pure charity i'm the product manager at pure charity and we you know one of the things that we always try to protect our developers against is you know their focus on future product and improvements and it seems like you know being able to validate those early and then maybe even earmark them as critical would help you save some time on the front end. Are they involved in that, or is there any way the community can kind of step up to help you do something like that? So I get a few contributors from time to time that help,

and that really helps, but because RVM is quite big it's over 20 lines 20 000 lines of shell code and the biggest problem is a shell code it's really it's really hard and there is no good standards for coding in shell so i had to develop good standards over the years I worked on RBM. And even I get contributions, I spend still quite a lot of time doing reviews, so nothing breaks for the users. Because if you don't check it, even if there are tests, because we got tests like last year,

and even there are tests, the tests don't catch everything because there is over i don't know 20 platforms supported right now so you can use rvm almost on every unix like system and but to get every contribution every code to work I have to still look on it just from the experience point to catch the small things that are that need to be that can't be tested right now. So you mentioned that it has 20,000 lines of shellcode, is that what you said? Yes. So that's a lot that's here on your and your plan for 2.0 one of the biggest changes is that you'd be switching to

writing it not in shell but in Ruby can you speak to that yes so the biggest problem with shell scripting is nobody knows it nobody knows how to write good shell code. And we've written a tool for Ruby. So if a Ruby developer wants to check something in the shell code, he can understand most of it. But to write a good code that will not slow down, because that's quite a hard thing to not slow down the shellcode. And that will not produce side effects in random environments because supporting both Bash and ZSH and in few flavors, in few versions, that's quite complicated.

And yes, so we want to switch to Ruby because everybody knows Ruby and there are already good practices. So you will not have to check every commit for code quality if it's even good formatted. It's already something people know how to do it. And we only will have to do minimal review for security for bugs, but nothing like now to search all the special cases where experience really counts. So, RVM installs Ruby for you, and you're switching Ruby to a dependency.

Surely you have a solution for getting Ruby onto the machine that you're going to use RVM to install Ruby on? Yes. So it was proposed to me for a few times to switch to Ruby because everybody knows Ruby. And it was before we got binary rubies in REM. So right now we got binary rubies, which basically is Ruby that's already compiled. You can just take it on your system, unpack it, and it's working,

if it's provided for your system. And if there is no binary Ruby for your system, second option will be JRruby which is really really stable now and you get java for almost every platform on the world so if there is no binary ruby you can still get it working with jruby and in in worst case a small thing that will be planned also for RBM2, maybe 2.5, is remote execution where you can run RBM locally on your system and install Ruby on a remote machine. So you don't have to install Rvm on every computer you will use Ruby.

You only install it locally and can use the local version to install Ruby on remote servers. So in the end, it will be possible to just install Ruby without installing Rvm or even prepare packages. So that's another option. So the plan is that you'll have a little bit of shell scripting or non-Ruby code that will download the binary Ruby and will use that to bootstrap and install other Rubys. Does it then discard that initial binary or is it resident on the machine or have you not even figured that kind of stuff out yet?

Yes, so for the initial setup, there will be shell script that's always needed because you can either write shell code or Python code. It depends on what is available on this remote system, but shell is something, the limited SH, SH shell, is available everywhere, like Basebox, you can get it working on every device that supports Linux. So minimal shell code will be available everywhere, and you can use it just to bootstrap. If there is binary Ruby, use it to download.

If it's not available, show instructions for JRuby or how to do the remote installation. Cool. So besides switching to Ruby, what are the other big plans for 2.0? For 2.0, the biggest plan is to stop being just Ruby version manager, start managing everything. It's another project from Wayne Seguin, SM Framework, which also was in share and did manage installation of software

and managing software, but not switching so all the installation part and it's rvm2 will be like putting the ideas of sm framework to to manage everything and the environment switching from rvm but in the end i'm still thinking about the switching part because I also helped with CHRuby and something small like CHRuby would be also possible. And maybe even we could integrate with CHRuby where RVM would be more for installation and for managing the internals of Ruby, like gem sets and so on. But to switch the environment in your local shell, you could use chruby. You talked a little bit about this in your talk at Rupa. You mentioned Python version manager as part of it. I didn't get a chance to watch the entire talk, but so it

sounds like not just Ruby versioning, but Python and others. Yes, yes. So basically the initial process for the version 2.0 will be to get Ruby and JavaScript binaries

available. So you can get your Rails applications really fast because right now when you get Ruby and want to start a Rails project, you still need JavaScript executable. And that will be the first step. That's the basic requirement for Rails project. So that will be the first thing. That's the basic requirement for RACE projects. So that will be the first thing that will be working just to

make sure we get compatibility with RACE projects. Second step will be integration with RubyGems because right now when you install Gems, you don't know which dependencies of the

Gems are needed. It's nothing automated. And in RubyGems, I think it was in 2.0, there is metadata, which you can use to describe your dependencies of your gem. And then with simple RubyGems plugin, you can connect RVvm and ruby gems where when you install a gem that has a dependency like nokogiri has libxml you can say require libxml libxsl t and rvm will know how to install them for your system so it will be automatic and the experience should be a lot better for final users so i'm just kind of thinking about uh this change and what this means and then i'm always a person that kind

of kicks back to name so does rvm become something that becomes shaky ground meaning does the name change or does it change or morph to a different acronym like Real Version Manager versus, and I guess when Wayne was on the show, so for those who have listened to the Change Lab for a while, you can go back to, I think it's episode 66. We had Wayne on and he talked about it and it wasn't actually called Ruby Version Manager, it's Environment Manager, right? Ruby Environment manager. It's environment manager, right? Ruby environment manager. Yes. So we got a page for RVM alternative implementations, and it says Ruby is not the only Ruby version manager, and Ruby is not the only one Ruby environment manager

because RVM does both right now. And in RVM 2, the code name for it is SM Framework, SMF, because it will be more based on SM Framework, the current implementation, which I think Wayne mentioned it back then as BDSM. Yeah. And since then, we changed the name first to SM and then SM Framework. Okay, cool.

I was wondering, because I know that Wayne kind of, that was an unexpected, I guess, topic for episode 66 when we talked about BDSM. I know Steve was really happy to talk about it as well on that show, so if you go back and listen to that, it'll definitely be a good primer for you to come back into this conversation here. But it was pretty neat and quite low-level and way over my head.

But it's still fun to listen to. Yes, so RBM2 will be like a mix of SM framework of BDSM and RVM. So does it, I guess coming back to that, does the name RVM become stale at that point? I know you said codename. Is the plan potentially to change that? Have you talked to anybody about that? Has the community kind of put their two cents in about the name change or even the potential of?

So I will not change the name. The name stays RVM2 because RVM has its brand and people know it, and it's really easy to identify the product with the name. So if anybody hears a new name it will be something totally new and the change might be harder and when you when you know it's the same product and it's compatible because that's as one of the aims to to get the code that's already out there and RVM1 is supporting it it should be also working with RVM2 so we do testing

outside testing where no internals of RVM are tested only the API what's CLI what's available to the user it's tested and we plan to pass the tests

for RVM2 so no we don't change the name it will stay we have some internal sometimes internal we refer it like a same framework but in the end it will be rvm2 gotcha i was during the conversation between you and Jared a bit there, I was also taking note that right now you're in the clear too in terms of issues. I was quite surprised to see that you have zero open issues right now on GitHub. I'm not sure if you track issues anywhere else, but that's a pretty cool feat to be at zero issues. You might be watching on the wrong repository. I'm still using winc be watching on the wrong repository. I'm still using wincgreen.rvm repository

and there are 12 open issues, at least there were 12 before we started and I used a flag feedback needed which means I did everything I could, need more information from the user

and 10 issues are feedback needed which means I did everything I could, need more information from the user, and 10 issues are feedback needed, so there are two issues I know I have to work on, and the rest 10 issues possibly could be something that RBM has to do, but in most cases that happens to be that it's only just clarifying how things work and asking for more information. And in the end, it's often a really small change.

That's weird. Every time I go to issues, it for some reason kicks me to milestone 17, which has no issues. So weird because I'm sitting there in issues and I'm like, there's no issues. But I go back to the nav, and I see issues in the sidebars. That's an aside. You need to clean the Milestone filter. That's either a GitHub bug or a feature. Yeah, I'm not sure which it is.

I was like, yay, no issues. I was like, that's cool. Let's mention that. Yeah, I got two weeks ago, I got two open issues only, and they were different than the two that I have right now. And yeah, I was really happy. And it was before a conference,

a RU camp, a JRubyConf EU. And during the conference, I don't know, I handled a lot of tickets. It's like some months I got over hundreds of tickets handled per month. Wow. So yeah. must be a lot of pressure I guess just kind of

having to potentially wake up the next morning like you go to bed the night before pretty happy and then you go to sleep and you wake up and you're like oh what happened you know yes so you mentioned I guess I mentioned this actually earlier in the show,

that you're the release manager of RVM at Engine Yard. Yes. So back when you very first started with RVM, kind of serendipitously was able to step away from your current job, take on responsibilities at RVM. We talked about the details around that. But now when you kind of stepped in to be the full maintainer of it, it was around the same time you started at EngineR too, right?

So it was like I worked on it just as a maintainer for two or three months, and then I got half-time as release manager for RVM, but it was only half-time and only year after, or one and a half year after, I got the offer to get full-time on RVM. And so what is it, you know, I guess, what does Engine Yards play here? I mean, obviously we understand what Engine Yard is

and the importance that they've played in the Ruby community over the years. But what's it like, I guess, being at Engine Yard and what does your role mean at Engine Yard being the release manager for RVM? So I don't have a lot of contact with Engine Yard. I get to the team meetings with Wayne and his team, but I don't do much work for Engineering Art. I do all the time RVM,

and only sometimes I get support questions for RVM products. And I work maybe two months part-time on a small project to integrate RVM with one of the clients. But in the end, I do most of the things like I did before. So I take care mostly of making sure that release is working properly. So I check all the tickets and make sure the version released will be stable. That's the thing that I was contacted by Engine Yard. Hey, we got some bugs. Wayne was not having much time at this point.

And I was the only other active maintainer at the time. So I was contacted by NJR because users got bugs. And because of the bugs with RVM, they were locked and they couldn't continue work. So they couldn't deploy applications to NJR. So if they couldn't deploy, they couldn't pay. So NJR needed somebody to provide working RVM so the clients can continue deploying applications and do their real work instead of fighting bugs. That's pretty neat the way that that works out, though, that they have such need for

RVM that they're capable and willing to support open source in a way where not only do me and Jared and the rest of the listeners listen to this show, get to enjoy the benefits of your work on RVM and the other contributors to that effort, but at the same time, you're full-time employed by Engine Yard to manage essentially the development of RVM. How much, can you talk a bit about how much, I guess, feedback you get from the deploy teams or the support teams at Engine Yard and how that feeds back into making RVM better by, you know, identifying different issues that might come up that otherwise may never be really found unless you're kind of in an enterprise scenario and you have to really support a large-scale application with Ruby is managed by RVM. So yeah, so it's the fun part is that Engine Yard itself doesn't use RVM internally. And something ago, like I don't know, year ago maybe a bit longer I was helping

with one of the managed clients to get RVM working because they wanted the switching part automatic not to do everything manually they wanted just to say we are switching Ruby, RVM

switch Ruby and ready not to ask the staff hey switch a Ruby for us, make the application working, move everything. And they wanted to make that thing automated with Rvm, and it's there, and I'm helping with that application, but so far it's just one application. So not a lot of feedback then from the support team. Yeah, not a lot.

But the application is quite big. They are one of the biggest customers. And I don't get any questions because everything is working. It works. You were going to say something, Jared? I was going to say that the engine yard employs you full-time to work on RVM and they largely just leave you alone. Is that what you're saying?

Because that would be awesome. Yeah, mostly, mostly, mostly. But you would say it's a really great situation to be in because you get paid and you don't have to answer before anybody and it's not true because i answer before the whole community and when i do something wrong i get like in one hour i get tickets and stack overflow questions. Very often somebody, in five minutes, somebody locks into IRTS and complains, hey, this is broken. Yeah, I'm not saying there's no pressure on you. I'm saying that it's awesome that you get to work on that, which you

are already doing in your free time. The thing you're passionate about, now you get to work on that. Yes. Kind of the open source dream. It's really great, but on the other hand, it's like it takes all your free time. It's really hard to find some time for something else. I needed to learn from the beginning how to take my free time to to just

have some sports to spend some time with kids it's not nothing like you get in real job like eight hours and you go because something always happens and it's not like you do it in eight hours and you quit, you get questions, you get support issues all the time, all the day, because everybody around the globe uses RBM. So you need to do the support almost 24-7. Yeah, it seems like a nice lifestyle job too, Jerry, doesn't it? I mean, to be employed full-time and hack on open source code and improve the lives of... At the same time, they'll be the

main burden bearer, if that's the case, to have to deal with the fact that... But like you've said, Michael, time and time again, that it works, right? Yes. So, I think two years ago when I started contributing, it was like there was a lot of job of supporting

people. And at every issue, I got some small ideas how to improve things, how to make less support. So I added warnings, automation, and things like autolips, which was added half a year ago. All the small things, all the small messages make everything working smooth. So I stopped getting like 10 requests daily, why bundler doesn't work, because right now RVM comes with RubyGems Bundler which integrates Bundler really with RubyGems.

That's the missing point of integration and it was really hard to get it working because RubyGems didn't want that integration. Bundler was afraid that it would break things, and I still hear from some sources that it's a really bad thing. But there are over 2 million downloads for the gem, and everybody is happy. And immediately when the support for RubyGems Bundler was introduced in RVM,

the amount of issues with Bundler not working dropped from 10 daily to zero. Wow. Well, just to give you some props, I mean, I've been an RVM user daily since I don't remember how far back, years. And I would say it's stabilized to a point where I barely have to think about it anymore

and I'm always, you know, RVM gets stable whenever there's new rubies out there and everything so far, for me at least, has been very smooth, especially in the last year. So you're doing a good job, man. Thank you. And just to kind of key out that one last point there too, is that RubyGems Bundler was merged into bundler 13 right it was planned but finally i was not able to do this oh i see so it's still an independent gem by itself then yes it's still independent gem but ruby gems 2.0 is already doing parts of Bundler work and the plan for RubyGems 2.1 is to take over everything.

So I'm not sure about the JIT gems, but it probably will be a plugin for RubyGems 2.1. So you could quit using Bundler and have all the functionalities in RubyGems, and RubyGems has already support for the automatic loading of the binaries with proper environment. So that gem will be then useless if people start switching to just pure RubyGems. Yeah, I don't know if we got a chance to really talk about it much, but we're close to being out of time. But did we really talk much about Autolibs and what that means?

That's what you're kind of keen off of there, right? Yeah, so Autolibs, I had it planned for a long time, and I was really holding back with implementation because i wanted to make it for rvm2 i wanted it to be the the major difference because it's something really it's planned for something bigger what's implemented right now it's just the minimal possible possible thing to make it working and for rM2, it's still a lot of things like integration with RubyGems, which is missing. And I was forced to get it implemented in RVM1

because of the switch in RubyGems to SSL HTTPS URL for getting gems because of security and this one requires OpenSSL and OpenSSL on every system installs in different way and it was quite easy to get Libyam

which is needed for gems to work because it's really small library you can compile it and it it works everywhere really simple but for open ssl i needed integration with the system because you can't compile open ssl if it's already there it will be taking more time than compiling Ruby itself. So then I had to implement Autolibs in the minimal version, which is just suitable for the shell coding. In shell, it's a really big project to get it working. In Ruby, it would be something quite simple. And so it was really challenging.

I don't know, Jared, if you have any more you wanted to mention before we tail off. We have a couple of common questions we asked, but if you've got anything else you want to mention, Jared, I'm cool with that too. Well, I was just hoping to nail Michael down on a guaranteed release date for RVM2. Come on, Michael.

What you got? Yeah, if people stop opening issues for RVM1, then Christmas will be something really possible. possible but it's not that easy to to stop getting tickets because with every handled thing there happens to be something really small that still needs to be handled and rvm1 is feature freezed for already a year and we still got small things that need to be included, like FUSE matching when you want to match 193 Ruby. And that was needed for Travis for support. And because Travis is right now the biggest customer of RVM, we got that feature implemented, Even we had feature freeze. So no more issues to 1.0 and 2.0 becomes a Christmas present.

Yes, yes. But I'm not sure about that. No more. No way. Crush your fingers. Probably won't happen. But all right. Well, maybe it might be a chance for someone to maybe step up and help you out, though.

So I guess that kind of tails into one of our common questions, which is, you know, for you, Michael, what is a call to arms, so to speak, for the community, the Ruby community? And I guess these other communities that might be stepping up that will eventually begin to use RVM as well, Python and others. What's a call to arms for RVM? How can the community step up and help you out to make our Christmases bright and beautiful with RVM 2.0? Yes, so the plan is to get the issues handled and to stop handling new features. And if users could help with limiting the amount of issues. If it's nothing really, really big, just help with documentation and help with handling issues.

Then that should allow a better start for RVM2. What's the best place to go for somebody interested in getting involved? Where should they start? So we've got quite good readme's for tests, for documentation, and for RVM quite good. It's lacking and if somebody wants to help and sees

problems with documentation that's not really what should happen then we got everything on github fork the documentation from RVM site,

and just improve it. Just improve it. That's a good tagline right there. So, Michael, one thing we like to ask our guests, and feel free to mention whomever means most to you, but who might be

a programming hero for you? It's hard to say. I really love the work of Wayne. Yeah, Wayne Seegreen. He did a great job with RVM, with SM Framework, and I'm really missing him in open source. Yes. I guess we mentioned too that Wayne has been on the changelog before episode.

We used to call it 0.6.6, but since we moved to 5x5, we started calling them by their real name. So back in the 60s, as we like to say, episode 66, you can kind of go back to kind of pick up. Michael, you can kind of go back to kind of pick up. Michael, you mentioned SM Framework. Wayne touches on BDSM back in that day, so it might be a good primer for you to go back and listen. And even another friend of the show is Sam Stevenson. We mentioned RBM on here as well.

Episode 64 is that show. He touches a little bit on how PAL supported RVM back in those days. And I think that was back, that episode was 2011. So it's kind of dated but still neat for a primer on some of these topics if you want to go back in time a bit. But you are Michael Papis on Twitter and GitHub. That's M. Papis, P-A-P-I-S, on Twitter. So I guess people want to follow you or kind of reach out to you to say hello or even just a thank you. That's where they should go, right? But is there anywhere else that people can kind of find you and kind of keep up with what you're up to?

Yes. So I'm all the time available on IRIS and all the time I mean it it's 16 hours a day and 7 days a week I'm available at IRIS channel hash rvm you can find me there you can talk to me and I help everybody as long as it's

Ruby and RBM related. And we definitely want to thank our sponsor for the show, for supporting the show, AppSketchbook. You can use the code DANSENTME Go to AppSketchbook.com

Save five bucks. Neat. I actually use it myself. Those are really neat. Whenever I sketch iPhone or iPad stuff, I'm always using that.at. I actually use it myself. Those are really neat. Whenever I sketch iPhone or iPad stuff, I'm always using that. Actually, I even used it whenever I was working on the responsive version of the Change Law Weekly's change design.

So it's kind of neat to map that out. But Michael, I want to thank you for joining us on this show today. Jared, for you being the co-host. And Andrew, who is missed today because he's not feeling so well. He had some sinus snafu but he did tee up this conversation with Michael

and the update on RVM so thanks to you Michael, Andrew and for you, the listeners for listening so let's take this moment and say goodbye. Goodbye everybody and thanks for having me. you