Hacker News Reader

Comment by dragonwriter | Hacker News Reader

> 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 solutions (unlike the Python solution) attempt to manage versions that are not even from the same project, which naturally makes a single dictatorial-blessed solution problematic, as there is no dictator (or even central project) for the entire Ruby ecosystem, even if there is for the mainline interpreter.

View on HN

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 basically made me go, ok fine, i'll go back to c this is getting ridiculous.

That plus clang has made me happy.

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.

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!

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.

> 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.

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.

Reply on news.ycombinator.com