Add Rubinius 2.10

[deepj]

No description provided.

[mislav]

Thanks!

[mislav]

Thanks!

[mislav]

Curiously, the checksum for rbx 2.10 changed since you've submitted this PR and this failed post-merge. I had to correct the checksum d9145d4. @brixen is republishing a tarball a thing that happens?

[mislav]

Curiously, the checksum for rbx 2.10 changed since you've submitted this PR and this failed post-merge. I had to correct the checksum d9145d4. @brixen is republishing a tarball a thing that happens?

[deepj]

@mislav I guess so. They change a lot of things in these days. Because I still have the old tarball on my disk and it returns a different checksum than current one :(

$ shasum -a 256 ~/Downloads/rubinius-2.10.tar.bz2
ca85b47e5067e024ab172f7fdf3a09c643027bc53e849a99826495efcebe503e

[deepj]

@mislav I guess so. They change a lot of things in these days. Because I still have the old tarball on my disk and it returns a different checksum than current one :(

$ shasum -a 256 ~/Downloads/rubinius-2.10.tar.bz2
ca85b47e5067e024ab172f7fdf3a09c643027bc53e849a99826495efcebe503e

[brixen]

@mislav we may push updated versions of the tarball. There is no reason to cache the digests. They are always available via HTTPS either from our S3 or in the GitHub release object. I realize that conflicts with rbenv's design, but frankly, it's flawed.

[brixen]

@mislav we may push updated versions of the tarball. There is no reason to cache the digests. They are always available via HTTPS either from our S3 or in the GitHub release object. I realize that conflicts with rbenv's design, but frankly, it's flawed.

[mislav]

We don't use the checksums in ruby-build just for security. We also use it to verify the download and to provide efficient mirroring via CloudFront.

To me, repushing tarballs after they have already been shared is as distasteful as force-pushing git tags. As a result, @deepj and I now both have "Rubinius 2.10" on our computers, but they are in fact different versions.

[mislav]

We don't use the checksums in ruby-build just for security. We also use it to verify the download and to provide efficient mirroring via CloudFront.

To me, repushing tarballs after they have already been shared is as distasteful as force-pushing git tags. As a result, @deepj and I now both have "Rubinius 2.10" on our computers, but they are in fact different versions.

[brixen]

@mislav S3 provides Etags, so efficient caching should not be a problem. A release is a label, much like a domain name. You're asking that a domain name always resolve to the same IP address. That's not the way the Internet works and it's not the way Rubinius releases work, for a good reason.

If a failure happens during building artifacts, we rebuild them. If something is borked when we label a release, we relabel it. By simply respecting the label and not insisting on what the label means, you can have a more useful system.

I can't eliminate failures in the process of making and deploying artifacts.

I also can't tell you how to architect your tool. But I can tell you that caching the version numbers or digests is not reasonable unless you also provide a sensible way to update them. Install tools are fundamentally distributed database tools. That's why, for example, you do apt-get update && apt-get install blah. Different packaging systems use different mechanism for labeling, but that's beside the point. You're fundamentally caching, and if you don't do invalidation correctly, you're introducing bugs.

Honestly, given the amount of time I've wasted with rbenv, RVM, and chruby bugs and insisting on telling me how Rubinius should build and package, it would be better if none of them installed Rubinius. You are insisting on a particular tradeoff in the architecture of a distributed system that is untenable.

[brixen]

@mislav S3 provides Etags, so efficient caching should not be a problem. A release is a label, much like a domain name. You're asking that a domain name always resolve to the same IP address. That's not the way the Internet works and it's not the way Rubinius releases work, for a good reason.

If a failure happens during building artifacts, we rebuild them. If something is borked when we label a release, we relabel it. By simply respecting the label and not insisting on what the label means, you can have a more useful system.

I can't eliminate failures in the process of making and deploying artifacts.

I also can't tell you how to architect your tool. But I can tell you that caching the version numbers or digests is not reasonable unless you also provide a sensible way to update them. Install tools are fundamentally distributed database tools. That's why, for example, you do apt-get update && apt-get install blah. Different packaging systems use different mechanism for labeling, but that's beside the point. You're fundamentally caching, and if you don't do invalidation correctly, you're introducing bugs.

Honestly, given the amount of time I've wasted with rbenv, RVM, and chruby bugs and insisting on telling me how Rubinius should build and package, it would be better if none of them installed Rubinius. You are insisting on a particular tradeoff in the architecture of a distributed system that is untenable.

[mislav]

If there was another tool that respects Rubinius' release principles and eases the installation or upgrade of latest Rubinius version on a system, I would gladly advocate its use over ruby-build. If a tool can drop a Ruby version into a directory like ~/.rbenv/versions or /opt/rubies, it can work with rbenv or chruby.

[mislav]

If there was another tool that respects Rubinius' release principles and eases the installation or upgrade of latest Rubinius version on a system, I would gladly advocate its use over ruby-build. If a tool can drop a Ruby version into a directory like ~/.rbenv/versions or /opt/rubies, it can work with rbenv or chruby.

[semaperepelitsa]

@brixen How would people know they've got a bad build if you don't change any version number?

[semaperepelitsa]

@brixen How would people know they've got a bad build if you don't change any version number?

[stefanpenner]

@semaperepelitsa he mentioned etags

[stefanpenner]

@semaperepelitsa he mentioned etags

[sstephenson]

Honestly, given the amount of time I've wasted with rbenv, RVM, and chruby bugs and insisting on telling me how Rubinius should build and package, it would be better if none of them installed Rubinius.

Fair enough. I’ve opened an issue to track the progress of removing Rubinius from ruby-build, at your request. Please feel free to weigh in there.

You are insisting on a particular tradeoff in the architecture of a distributed system that is untenable.

I’m not sure I follow your argument. This has nothing to do with the architecture of distributed systems. Rather, it’s about being able to reliably and reproducibly install the same version of Ruby at any point in time—be it today, a week from today, or a year from today.

From the first few sentences of rbenv’s readme:

Use rbenv to pick a Ruby version for your application and guarantee that your development environment matches production. […] Specify your app's Ruby version once, in a single file. Keep all your teammates on the same page.

That’s more or less the guiding philosophy of rbenv and ruby-build: to help ensure everyone on a team has a fully specified development environment that matches production and can be recreated at any time. Which is why we avoid changing ruby-build definition files after they’re released (except for OpenSSL security patches), and why we don’t support fuzzy version matching in rbenv (you must specify an exact version number).

But what you’re saying is that, in contrast to nearly every other open-source software project, the same Rubinius version number can point to different releases over time. A mutable versioning scheme means reproducible installations are impossible. So it does indeed sound like Rubinius is incompatible with rbenv’s philosophy and is not a good fit for inclusion in ruby-build.

I can't eliminate failures in the process of making and deploying artifacts.

“Failures in the process of making and deploying artifacts” is quite an elaborate way to write “bugs.” Of course you can’t avoid releasing buggy versions of Rubinius. But you can fix the bugs later and issue new releases with incremented version numbers. This is how software works.

You’re free to choose your battles, but reinventing versioning seems like an odd one to pick. Personally, I can’t imagine anyone would feel comfortable deploying Rubinius in production knowing that version 2.10 installed yesterday might be a different piece of software from version 2.10 installed today. But I trust you know what’s best for your project, so we’ll part ways here.

[sstephenson]

Honestly, given the amount of time I've wasted with rbenv, RVM, and chruby bugs and insisting on telling me how Rubinius should build and package, it would be better if none of them installed Rubinius.

Fair enough. I’ve opened an issue to track the progress of removing Rubinius from ruby-build, at your request. Please feel free to weigh in there.

You are insisting on a particular tradeoff in the architecture of a distributed system that is untenable.

I’m not sure I follow your argument. This has nothing to do with the architecture of distributed systems. Rather, it’s about being able to reliably and reproducibly install the same version of Ruby at any point in time—be it today, a week from today, or a year from today.

From the first few sentences of rbenv’s readme:

Use rbenv to pick a Ruby version for your application and guarantee that your development environment matches production. […] Specify your app's Ruby version once, in a single file. Keep all your teammates on the same page.

That’s more or less the guiding philosophy of rbenv and ruby-build: to help ensure everyone on a team has a fully specified development environment that matches production and can be recreated at any time. Which is why we avoid changing ruby-build definition files after they’re released (except for OpenSSL security patches), and why we don’t support fuzzy version matching in rbenv (you must specify an exact version number).

But what you’re saying is that, in contrast to nearly every other open-source software project, the same Rubinius version number can point to different releases over time. A mutable versioning scheme means reproducible installations are impossible. So it does indeed sound like Rubinius is incompatible with rbenv’s philosophy and is not a good fit for inclusion in ruby-build.

I can't eliminate failures in the process of making and deploying artifacts.

“Failures in the process of making and deploying artifacts” is quite an elaborate way to write “bugs.” Of course you can’t avoid releasing buggy versions of Rubinius. But you can fix the bugs later and issue new releases with incremented version numbers. This is how software works.

You’re free to choose your battles, but reinventing versioning seems like an odd one to pick. Personally, I can’t imagine anyone would feel comfortable deploying Rubinius in production knowing that version 2.10 installed yesterday might be a different piece of software from version 2.10 installed today. But I trust you know what’s best for your project, so we’ll part ways here.

[brixen]

@sstephenson I'd suggest you review the fallacies of distributed computing.

A "bug" is not the extent of a problem with deployment. In the Rubinius pipeline ecosystem there are at least GitHub, Travis (and multiple OS versions and container or VM configurations that Rubinius has no control over), S3, GitHub Pages (which implies a CDN), etc.

There's a reason systems like DNS exists. But like you said, pick your battles. You seem to think some platonic ideal of "reproducibility" is paramount. I think that a resilient system of signaling and process is paramount.

I'm happy to part ways. Thanks.

[brixen]

@sstephenson I'd suggest you review the fallacies of distributed computing.

A "bug" is not the extent of a problem with deployment. In the Rubinius pipeline ecosystem there are at least GitHub, Travis (and multiple OS versions and container or VM configurations that Rubinius has no control over), S3, GitHub Pages (which implies a CDN), etc.

There's a reason systems like DNS exists. But like you said, pick your battles. You seem to think some platonic ideal of "reproducibility" is paramount. I think that a resilient system of signaling and process is paramount.

I'm happy to part ways. Thanks.

[shyouhei]

In the Rubinius pipeline ecosystem there are at least GitHub, Travis (and multiple OS versions and container or VM configurations that Rubinius has no control over), S3, GitHub Pages (which implies a CDN), etc.

A good reason for MRI to avoid moving to git, if this is a true story. We (MRI maintainers) also did break MRI releases some times before. But that were our (human) errors, not build pipeline. Introducing git would be likely to cause extra problems, it sounds.

[shyouhei]

In the Rubinius pipeline ecosystem there are at least GitHub, Travis (and multiple OS versions and container or VM configurations that Rubinius has no control over), S3, GitHub Pages (which implies a CDN), etc.

A good reason for MRI to avoid moving to git, if this is a true story. We (MRI maintainers) also did break MRI releases some times before. But that were our (human) errors, not build pipeline. Introducing git would be likely to cause extra problems, it sounds.

[headius]

@shyouhei: JRuby has been using git, Github, Travis, Github Pages, S3, Jenkins, Maven, and a half dozen other tools for years. Bugs happen. Botched releases happen (notice there's no 9.0.3). But the problems are nearly always human error...certainly not git and usually none of the other tools either.

[headius]

@shyouhei: JRuby has been using git, Github, Travis, Github Pages, S3, Jenkins, Maven, and a half dozen other tools for years. Bugs happen. Botched releases happen (notice there's no 9.0.3). But the problems are nearly always human error...certainly not git and usually none of the other tools either.

[brixen]

@shyouhei I listed at least 4 different components, only one of them is git. Our use of git (and GitHub) for many years has been one of the best things for the project. I still remember fondly being told by another project that it was none of our business when we recommended using git over something like Mercurial or some other less useful VCS. They use git (and GitHub) now. If you use git, that will be the least of your worries.

The point I was making is that these collections of systems are distributed systems, and those have behaviors that you cannot control, no matter how many geniuses believe that CAP isn't a thing. The 8 fallacies of distributed computing explains this very well.

In Rubinius, a "version" is a label on a git commit. To find exactly which commit (uniquely identified by its SHA) the version labels, you deference the corresponding git tag. If, for some reason, you have cached the tuple (version, SHA), you can verify it or update it by dereferencing it again. There are many distributed systems that function like this and it turns out to have really useful properties. There is nothing in the universe that compels caching the result; it's merely a choice.

In this case, rbenv chooses to cache the result the first time they dereference it, but don't want to use any mechanism to update the cache. Of course, choosing to build a system with a fundamental flaw in it is something they are perfectly free to do, but they aren't free to claim that their choice is some immutable law of the universe and anyone who disagrees with them is wrong.

So please don't claim that git has anything to do with problem. It doesn't.

[brixen]

@shyouhei I listed at least 4 different components, only one of them is git. Our use of git (and GitHub) for many years has been one of the best things for the project. I still remember fondly being told by another project that it was none of our business when we recommended using git over something like Mercurial or some other less useful VCS. They use git (and GitHub) now. If you use git, that will be the least of your worries.

The point I was making is that these collections of systems are distributed systems, and those have behaviors that you cannot control, no matter how many geniuses believe that CAP isn't a thing. The 8 fallacies of distributed computing explains this very well.

In Rubinius, a "version" is a label on a git commit. To find exactly which commit (uniquely identified by its SHA) the version labels, you deference the corresponding git tag. If, for some reason, you have cached the tuple (version, SHA), you can verify it or update it by dereferencing it again. There are many distributed systems that function like this and it turns out to have really useful properties. There is nothing in the universe that compels caching the result; it's merely a choice.

In this case, rbenv chooses to cache the result the first time they dereference it, but don't want to use any mechanism to update the cache. Of course, choosing to build a system with a fundamental flaw in it is something they are perfectly free to do, but they aren't free to claim that their choice is some immutable law of the universe and anyone who disagrees with them is wrong.

So please don't claim that git has anything to do with problem. It doesn't.

[brixen]

@shyouhei also, just to be clear, the Rubinius versioning scheme is no different than MRI's, where MRI uses MAJOR.MINOR.TEENY.pXYZ (eg 2.2.3p9000) and Rubinius uses MAJOR.MINOR(SHA). We don't put the SHA in the version string, but it's available via RUBY_DESCRIPTION and by dereferencing the v{MAJOR.MINOR} git tag.

The only difference is that we don't make arbitrary previous versions available, which has absolutely no significance whatsoever. There's no law of the universe that says previous versions must be available and we regularly cull previous binary builds and tarballs. Eventually, we'll surely do the same with all git tags (and git history) older than a certain date (but will likely put the previous git history in a separate repository).

This is just to say that any distinction that rbenv is desperate to make between the Rubinius version scheme and others, like MRI's, is not meaningful. They don't want to change their tool, which is fine. But the reason for the problem is their tool, not the Rubinius version scheme, or git.

[brixen]

@shyouhei also, just to be clear, the Rubinius versioning scheme is no different than MRI's, where MRI uses MAJOR.MINOR.TEENY.pXYZ (eg 2.2.3p9000) and Rubinius uses MAJOR.MINOR(SHA). We don't put the SHA in the version string, but it's available via RUBY_DESCRIPTION and by dereferencing the v{MAJOR.MINOR} git tag.

The only difference is that we don't make arbitrary previous versions available, which has absolutely no significance whatsoever. There's no law of the universe that says previous versions must be available and we regularly cull previous binary builds and tarballs. Eventually, we'll surely do the same with all git tags (and git history) older than a certain date (but will likely put the previous git history in a separate repository).

This is just to say that any distinction that rbenv is desperate to make between the Rubinius version scheme and others, like MRI's, is not meaningful. They don't want to change their tool, which is fine. But the reason for the problem is their tool, not the Rubinius version scheme, or git.

[semaperepelitsa]

Ruby-build can adopt this kind of version format for Rubinius: "2.10-14deac8c305395dda2ed981087c972ec2e543ef2".

[semaperepelitsa]

Ruby-build can adopt this kind of version format for Rubinius: "2.10-14deac8c305395dda2ed981087c972ec2e543ef2".

[sferik]

@semaperepelitsa True, but that would require rbenv users to type:

rbenv shell rbx-2.10-14deac8c305395dda2ed981087c972ec2e543ef2

[sferik]

@semaperepelitsa True, but that would require rbenv users to type:

rbenv shell rbx-2.10-14deac8c305395dda2ed981087c972ec2e543ef2

[brixen]

@sferik why would it? We users of git commonly use abbreviate SHAs all the time, and the SHA would only be needed to match if there were ambiguity in the label, which is almost never. Why is having rbenv provide useful matching an unreasonable thing?

[brixen]

@sferik why would it? We users of git commonly use abbreviate SHAs all the time, and the SHA would only be needed to match if there were ambiguity in the label, which is almost never. Why is having rbenv provide useful matching an unreasonable thing?

[sferik]

@brixen So you’re suggesting that users would normally be able to use the abbreviated command:

rbenv shell rbx-2.10

But as soon as an ambiguous, this command would fail and the user would be required to type:

rbenv shell rbx-2.10-14deac8c305395dda2ed981087c972ec2e543ef2

That does not seem like a very good user experience, but it is one possible solution.

The problem with using Git hashes in version numbers is that they are not sortable, so it’s impossible to tell which one is the latest.

[sferik]

@brixen So you’re suggesting that users would normally be able to use the abbreviated command:

rbenv shell rbx-2.10

But as soon as an ambiguous, this command would fail and the user would be required to type:

rbenv shell rbx-2.10-14deac8c305395dda2ed981087c972ec2e543ef2

That does not seem like a very good user experience, but it is one possible solution.

The problem with using Git hashes in version numbers is that they are not sortable, so it’s impossible to tell which one is the latest.

[defeated]

@sferik @brixen if an updated Rubinius tarball was released, wouldn't users of ruby-build only want the latest sha? (E.g. one replaces the other.) Otherwise it sounds like there would/should be a different .patchlevel release?

Would be a shame to see part ways over this =/

[defeated]

@sferik @brixen if an updated Rubinius tarball was released, wouldn't users of ruby-build only want the latest sha? (E.g. one replaces the other.) Otherwise it sounds like there would/should be a different .patchlevel release?

Would be a shame to see part ways over this =/

[sferik]

wouldn't users of ruby-build only want the latest sha?

Assuming the answer is yes, how can we reliably know which is the latest? It’s not encoded into the version number. What else should we look at to know which is the latest? Some HTTP header? This seems unreliable. The Rubinius git history? This seems slow. Any other ideas?

[sferik]

wouldn't users of ruby-build only want the latest sha?

Assuming the answer is yes, how can we reliably know which is the latest? It’s not encoded into the version number. What else should we look at to know which is the latest? Some HTTP header? This seems unreliable. The Rubinius git history? This seems slow. Any other ideas?

[brixen]

@sferik curl http://releases.rubinius.com/index.txt and dereference the file at https://rubinius-releases-rubinius-com.s3.amazonaws.com

[brixen]

@sferik curl http://releases.rubinius.com/index.txt and dereference the file at https://rubinius-releases-rubinius-com.s3.amazonaws.com

[rst]

A comment from the peanut gallery: MRI has not used the .pXXX numbers in their official releases in any of the 2.1, 2.2, or now 2.3 series -- the last release series that does use them is 2.0.x, which is approaching end-of-life. Also, those do allow anyone to determine which of two releases is more recent by inspection, without consulting any external resource.

[rst]

A comment from the peanut gallery: MRI has not used the .pXXX numbers in their official releases in any of the 2.1, 2.2, or now 2.3 series -- the last release series that does use them is 2.0.x, which is approaching end-of-life. Also, those do allow anyone to determine which of two releases is more recent by inspection, without consulting any external resource.

[MichaelSp]

that would require rbenv users to type:
rbenv shell rbx-2.10-14deac8c305395dda2ed981087c972ec2e543ef2

I use bash_completion for this. I'm glad that rbenv has covered that.

[MichaelSp]

that would require rbenv users to type:
rbenv shell rbx-2.10-14deac8c305395dda2ed981087c972ec2e543ef2

I use bash_completion for this. I'm glad that rbenv has covered that.