Simple, optional tarball cache support #232

Merged
merged 1 commit into from Nov 13, 2012

Conversation

Projects
None yet
2 participants
@lloeki
Contributor

lloeki commented Nov 7, 2012

Rationale

Both in development and in production, some usage patterns of ruby-build
are slowed down by the download phase. In scenarios such as
troubleshooting failing builds or with provisioning situations (chef,
vagrant...) the repeated download is unnerving, bandwidth wasting and
simply against etiquette towards tarball hosters.

It also happens that some source sites happen to be down and in such
cases it is helpful to be able to sideload sources to rbenv.

Behavior

By default nothing changes.

If the variable CACHE_PATH is set, then ruby-build will use that
directory to store a successful download, and will check before
downloading if the tarball is already there, in which case downloading
is skipped.

The file is first downloaded as before in the tmp subdirectory and only
moved afterwards, thus ensuring consistency.

There is no default cache path and the optional variable is to be set by
hand, ensuring people know what they're doing when using ruby-build.

Additionnally, rbenv-install will helpfully set CACHE_PATH if and only
if a RBENV_ROOT/cache directory exists. Again, the directory has to be
created manually.

The CACHE_PATH variable internally ends with a slash to mutualize
non-cached cases. Still, consistency is ensured whether or not a slash
is provided externally.

Notes

I'm not quite sure CACHE_PATH is a good name, maybe
RUBY_BUILD_CACHE_PATH is better and less conflicting.

Simple, optional tarball cache support
Rationale:

Both in development and in production, some usage patterns of ruby-build
are slowed down by the download phase. In scenarios such as
troubleshooting failing builds or with provisioning situations (chef,
vagrant...) the repeated download is unnerving, bandwidth wasting and
simply against etiquette towards tarball hosters.

It also happens that some source sites happen to be down and in such
cases it is helpful to be able to sideload sources to rbenv.

Behavior:

By default nothing changes.

If the variable CACHE_PATH is set, then ruby-build will use that
directory to store a successful download, and will check before
downloading if the tarball is already there, in which case downloading
is skipped.

The file is first downloaded as before in the tmp subdirectory and only
moved afterwards, thus ensuring consistency.

There is no default cache path and the optional variable is to be set by
hand, ensuring people know what they're doing when using ruby-build.

Additionnally, rbenv-install will helpfully set CACHE_PATH if and only
if a RBENV_ROOT/cache directory exists. Again, the directory has to be
created manually.

The CACHE_PATH variable internally ends with a slash to mutualize
non-cached cases. Still, consistency is ensured whether or not a slash
is provided externally.

Notes:

I'm not quite sure CACHE_PATH is a good name, maybe
RUBY_BUILD_CACHE_PATH is better and less conflicting.
@sstephenson

This comment has been minimized.

Show comment
Hide comment
@sstephenson

sstephenson Nov 7, 2012

Contributor

Beautiful patch, and fits right in with the ruby-build ethos. +1 from me.

Implementation-wise, I'd prefer CACHE_PATH to be normalized not to have a trailing slash, because "${CACHE_PATH}/${package_name}.tar.gz" reads clearer to me. But that's just a nit-picking detail.

And yeah, let's go with RUBY_BUILD_CACHE_PATH, to mirror RUBY_BUILD_BUILD_PATH. We'll also need to document it in the readme.

Contributor

sstephenson commented Nov 7, 2012

Beautiful patch, and fits right in with the ruby-build ethos. +1 from me.

Implementation-wise, I'd prefer CACHE_PATH to be normalized not to have a trailing slash, because "${CACHE_PATH}/${package_name}.tar.gz" reads clearer to me. But that's just a nit-picking detail.

And yeah, let's go with RUBY_BUILD_CACHE_PATH, to mirror RUBY_BUILD_BUILD_PATH. We'll also need to document it in the readme.

@lloeki

This comment has been minimized.

Show comment
Hide comment
@lloeki

lloeki Nov 7, 2012

Contributor

OK, I'll do the RUBY_BUILD_CACHE_PATH and a bit of readme doc later on.

I initially considered CACHE_PATH trailing slash normalization as you mentioned, as I agree it usually feels more readable, yet in this case it makes the code flow feel hairier, like too nested, when it actually doesn't need to be. Also, it makes duplicate tar or introduce an intermediate variable, again without need. Whatever, if you feel it's better normalizing it without a trailing slash, I'll do the change too.

Contributor

lloeki commented Nov 7, 2012

OK, I'll do the RUBY_BUILD_CACHE_PATH and a bit of readme doc later on.

I initially considered CACHE_PATH trailing slash normalization as you mentioned, as I agree it usually feels more readable, yet in this case it makes the code flow feel hairier, like too nested, when it actually doesn't need to be. Also, it makes duplicate tar or introduce an intermediate variable, again without need. Whatever, if you feel it's better normalizing it without a trailing slash, I'll do the change too.

@sstephenson

This comment has been minimized.

Show comment
Hide comment
@sstephenson

sstephenson Nov 7, 2012

Contributor

Thanks! Yeah, an intermediate variable sounds best.

Contributor

sstephenson commented Nov 7, 2012

Thanks! Yeah, an intermediate variable sounds best.

@sstephenson sstephenson merged commit 776c6e1 into rbenv:master Nov 13, 2012

@sstephenson

This comment has been minimized.

Show comment
Hide comment
@sstephenson

sstephenson Nov 13, 2012

Contributor

I went ahead and merged your patch with the changes above. (We still need documentation.) Thank you!

Contributor

sstephenson commented Nov 13, 2012

I went ahead and merged your patch with the changes above. (We still need documentation.) Thank you!

@fgrehm fgrehm referenced this pull request in alup/puppet-rbenv Nov 14, 2012

Merged

Creates cache folder for rbenv installations #49

viniciusteles pushed a commit to viniciusteles/puppet-rbenv that referenced this pull request Dec 11, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment