Rename dev versions

[rubys]

Address the bulk of what I originally set out to do. See comments on rubys@879e1c5

[sferik]

@sstephenson @jeremy Any reason not to merge this? It looks good to me.

[jeremy]

Feels like the multipass change could be seen through to a cleaner conclusion. Sourcing the build definition twice with a special PASS flag is some indication that the build functions should be broken into smaller parts so the git builds can explicitly fetch then make while the other tarball builds can use a bundled fetch+make.

[rubys]

I must confess that I don't understand the requirement for a bundled fetch+make. In fact, as an end user, I would argue the opposite: fetch failures are often intermittent and restartable, whereas make failures are less so. I actually find it appealing to have ruby-build first fetch everything it might need before it invests the effort in building, but that might just be me. In any case, a follow-on effort could take this to the logical conclusion, and make sure that all of the built in fetch operations are restartable -- either though the expediency of doing the fetch first to a temporary location and then to move it, or by employing restartable operations.

Looking at the specifics of the current build definitions as they exist in my pull request, splitting the install_git into smaller steps would involve repeating the branch name twice, a suboptimal outcome.

I would suggest that the ideal solution would involve treating the build definitions as declarative instead of imperative, and thereby be more a specification of what is desired and less of a prescription as to how to do it. Given the limitations of shell scripts, the current design of build definitions does a wonderful job of giving the appearance of being declarative.

That being said, the current implementation is decidedly imperative, which means that any change has the possibility of breaking existing user provided build definitions. If such definitions use the provided primitives like install_git, they will continue to work, but if they provide their own primitives or embedded logic, they might need to be modified.

[sstephenson]

Hey Sam. I'm sorry I haven't given this the attention it deserves. You've given me a lot to think about. I promise to have an answer soon.

[sstephenson]

Double-sourcing the definition is a smell. Here's what I think we should do:

1. Add a new command-line flag to ruby-build to enable "dynamic prefixes" (name TBD); rbenv-install enables this flag by default.
2. Memoize fetch_git so it only runs once per ruby-build invocation.
3. Allow definitions to define a function that computes a "dynamic prefix." The function takes the basename of $PREFIX_PATH and returns a transformed basename. For dev definitions, this will mean calling fetch_git to find the revision, then replacing -dev with that revision.

[mislav]

What does this patch do? I'd like to avoid pulling it, if it's not terribly necessary. It adds some complex code.

[rubys]

I'll describe the root problem to be solved: if I build the HEAD/master version of Ruby 2.1.0 given day, and then repeat that a week or a month later, the results should be two versions of ruby, with distinct names.

Another way to describe this: ruby-2.1.0-dev is an inappropriate name for a rbenv version, it isn't precise in that two different machines could have two different versions of ruby by that name.

[mislav]

Hey @rubys, thanks for your work on this, but I'm dropping it.

1. The code added is a bit scary, especially because our current code for fetching and building ruby is already getting a bit unwieldy and hard to grok for a first-timer.

2. The outcome of a rbenv install or ruby-build operation should be predictable; i.e. you should know what directory/version name you're ending up with. After this change, installing a version to /path/to/2.1.0-dev would result in an actual directory named /path/to/2.1.0-{SHA}, which you can't predict and you must ls the parent directory after the operation to see what you ended up with. Moreover, if you accumulate multiple directories named in the /path/to/2.1.0-{SHA} format, you can't tell which one is the newest anyway.

3. This should ideally get handled in user scripts that wrap ruby-build, e.g.:

   $ ruby-build 2.1.0-dev `rbenv root`/versions/ruby-2.1.0-dev-`date "+%Y.%m.%d"`