Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engine Yard's sponsorship of RVM is coming to an end

rvm.io

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Engine Yard's sponsorship of RVM is coming to an end

#61

Post by regularfry »

SingAlong wrote: post #25
knodi wrote: post #12

Is gem set management still required if using bundler?

Not required if you use bundler. But after you are done with the project, there is no easy way to delete the gems that the project uses all at once.

It's not required if you use bundler, but I'd argue it's still a good idea. If you can avoid a runtime dependency on bundler, you probably should.

> But after you are done with the project, there is no easy way to delete the gems that the project uses all at once.

This is part of why I wrote gemenv (https://github.com/regularfry/gemenv.git). It gives you a $GEM_HOME in the project directory, in the style of virtualenv.

Re: Engine Yard's sponsorship of RVM is coming to an end

#62

Post by regularfry »

mh- wrote: post #60
regularfry wrote: post #55

Earlier quoted context omitted.

I'm actually quite interested in how to fix that. The naive solution that springs to mind is sticking a local cache between my dev environment and the upstream sources, where I can control precisely what versions are available. Is that doable?

have a look at godep: https://github.com/kr/godep

Precisely the sort of thing I'm looking for. Thanks!

Re: Engine Yard's sponsorship of RVM is coming to an end

#63

Post by calineczka »

Some time ago I blogged about how we stopped using RVM in production: http://blog.arkency.com/2012/11/one-app-one-user-one-ruby/ . Many people here said that RVM might be over-complicated for the simplest cases and I think in production when there is only one app is the most simple usecase that you can get and RVM is overkill in such situation. In development however RVM is awesome, especially when you are a contractor or freelancer or you work on multiple open source ruby projects and gems and must switch between ruby versions often.

Michał Papis, the current maintainer is a great person and I wish him best luck in funding the project. If you want to meet him in person, he will probably be at wroc_love.rb 2014 conference ( https://twitter.com/wrocloverb ) . Check out what he learned so far on working with RVM1 and what are the plans for RVM2: http://www.youtube.com/watch?v=wN-iIC3S1ZM . I remember that some of the ideas for RVM2 were invented after our Ruby User Group meeting at 3 a.m. in the night, when we were trying to think about most science fiction approaches to RVM such as even a client server architecture. That was a crazy night :)

The biggest problem with RVM1 is that it is written in shell and even if there are people from Ruby community that would like to support this project, their skills are in Ruby language, not bash or zsh, etc. There are plenty of people who would like to help maintaining RVM but they just hit the wall when they see the amount of bash code in the project.

Re: Engine Yard's sponsorship of RVM is coming to an end

#64

Post by EamonLeonard »

jballanc wrote: post #17

So Engine Yard ends their support of JRuby in 2012. Then, just a few weeks ago, they end support for Rubinius. Now, they'll be ending support for RVM next week... A shift in strategy? Financial troubles? Either way, it seems they need to update their "Engine Yard Loves Open Source" page: https://www.engineyard.com/community/open-source

I'm Eamon Leonard, I work at Engine Yard.

We have a long history of supporting and investing in Open Source projects, especially those that can benefit our customers and the different OSS communities we participate in.

Like all companies, we have budgets for all sorts of activities, and sponsoring open source software is no exception. Also, like every other company, we review on an annual basis, where we allocate our budgets.

The decision to stop financially supporting any project is down to our assessment of what we've been able to help that project to achieve, and if there are opportunities to invest in other projects that are at a different stage in development, or if it relates to a specific customer need.

As has been pointed out elsewhere in this thread, the Engine Yard platform now supports Ruby, PHP and Node JS, and will soon be supporting Java, as well as a number of different databases.

Engine Yard has always contributed to the communities that its customers come from, and adding platform support for these languages and databases means that we need to consider open source projects in those communities as beneficiaries of our financial support.

Re: Engine Yard's sponsorship of RVM is coming to an end

#65

Post by crymer11 »

SingAlong wrote: post #25
knodi wrote: post #12

Is gem set management still required if using bundler?

Not required if you use bundler. But after you are done with the project, there is no easy way to delete the gems that the project uses all at once.

If you bundle install with the `--path` flag (which you should), you can specify the location the gems will be installed (typically something like `--path vendor`) which gives you the ability to easily remove the gems the project uses all at once.

Coupled with `bundle package` which stores all the .gem files in vendor/cache, you can ensure that your application always has its gem dependencies available.

Here's a great article with more information about all the above: http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-a...

Re: Engine Yard's sponsorship of RVM is coming to an end

#66

Post by jrochkind1 »

dragonwriter wrote: post #16
jrochkind1 wrote: post #11

Earlier quoted context omitted.

> often issues like dependency management (there are others) simply cause marginal developers to leave. I think that's true, and true in just about every language/environment, it's not unique to ruby, right? Dependency management often causes marginal developers to leave, in many langauges/environments. Dependency management itself has gotten a lot better in ruby -- bundler is pretty great. But multiple ruby version…

> I think that's true, and true in just about every language/environment, it's not unique to ruby, right? There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code. > I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be. As I understand, the competing Ruby…

> There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code.

At first I nodded my head to myself, but after thinking about it, I'm not actually sure that's true.

You can still have dependencies with binary distribution (if using dynamic linking etc). apt, yum, etc, were invented to deal with this right?

And it can still be a nightmare if you have two different things on your system that need different versions of the same dependency -- even a binary dependency. Have you tried to deal with two different binaries that need different versions of libxml? It can be nightmarish.

Re: Engine Yard's sponsorship of RVM is coming to an end

#67

Post by dragonwriter »

jrochkind1 wrote: post #66
dragonwriter wrote: post #16

Earlier quoted context omitted.

> I think that's true, and true in just about every language/environment, it's not unique to ruby, right? There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code. > I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be. As I understand, the competing Ruby…

> There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code. At first I nodded my head to myself, but after thinking about it, I'm not actually sure that's true. You can still have dependencies with binary distribution (if using dynamic linking etc). apt, yum, etc, were invented to deal with this right? And it can still be a nightm…

The dependency management issues that come with distributing interpreted source like Ruby are superset of the issues that come with binary distribution.

That's not to say that binary distributions can't also have dependency nightmares.

Re: Engine Yard's sponsorship of RVM is coming to an end

#68

Post by jrochkind1 »

dragonwriter wrote: post #67
jrochkind1 wrote: post #66

Earlier quoted context omitted.

> There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code. At first I nodded my head to myself, but after thinking about it, I'm not actually sure that's true. You can still have dependencies with binary distribution (if using dynamic linking etc). apt, yum, etc, were invented to deal with this right? And it can still be a nightm…

The dependency management issues that come with distributing interpreted source like Ruby are superset of the issues that come with binary distribution. That's not to say that binary distributions can't also have dependency nightmares.

I'm still suspicious. What's an example of a category of dependency problem that only effects interpreted source and not binary? I can't think of any.

Whether the files on disk are machine code (binary) that will be executed directly by the machine, or some other kind of code that will be executed by an interpreter -- I can't think of any dependency issues effected by that.

Ah, wait I can think of exactly one, issues with depending on a certain version of the interpreter. That's it.

Re: Engine Yard's sponsorship of RVM is coming to an end

#69

Post by mitchty »

hox wrote: post #38
mitchty wrote: post #29

Earlier quoted context omitted.

This is the exact reason I'm migrating new things straight to go. Once I've gotten the updated blob (binary or script/whatever really) to where it needs to be. I'm done, at compile time I can deal with dependencies, don't need to have a metric ton of stat calls flying around from require and other nonsense. I'm getting to the point that the troubles encountered with Python/Perl/Ruby and dependency management has basi…

Yet go is a dependency nightmare! Dealing with more than one developer on a project with dependencies is incredibly difficult due to the insane decision to not support locking a dependency to a specific version.

Our quick "solution", was just tar cvf up the dependencies and use that.

Alternatively godep as noted below, or you could get creative with git submodules or clone the repos to a local cache.

The reason go is simpler is you only need to deal with this at compile time, and thats what the ci server is for. My goal is removing runtime checks for crap and dealing with package versions every time I update things.

Go is more akin to c really here, and in my not so humble opinion it is a simpler task to sort out dependencies at compile time than on every system I need to deploy to.

Re: Engine Yard's sponsorship of RVM is coming to an end

#70

Post by jrochkind1 »

regularfry wrote: post #54
jrochkind1 wrote: post #11

Earlier quoted context omitted.

> often issues like dependency management (there are others) simply cause marginal developers to leave. I think that's true, and true in just about every language/environment, it's not unique to ruby, right? Dependency management often causes marginal developers to leave, in many langauges/environments. Dependency management itself has gotten a lot better in ruby -- bundler is pretty great. But multiple ruby version…

The "bundle exec dance" is unnecessary. Bundler doesn't need to be more integrated, it needs to be less integrated. Half the mess people get into is because the boundaries between these systems break down.

What do you do instead of 'bundle exec' to execute ruby command line utilities using the desired dependency tree?
Post reply on HN