Skip to content

Add :decorate and :overwrite subcommands to git (:git_* for gem) #898

Closed
hedgehog opened this Issue Dec 8, 2010 · 12 comments

3 participants

@hedgehog
hedgehog commented Dec 8, 2010

At the moment Bundler decorates the gem name with a hash when creating the folder name for a gem it pulls locally:

<gemspec_name>-<hash>

It would be useful to be able to

  1. Prevent this from happening (default :decorate => true),
  2. Still allow Bundler to error out if the folder already exists (default: :overwrite => false):

Example:
gem 'mygem', :git => "#{giturl}", :git_decorate => false, :git_overwrite => true

Is this something you would consider pulling into upstream? (Up to now, I've been assuming that closing tickets mean related pull requests will be ignored/rejected) If yes, which branch?

@indirect
Bundler member
indirect commented Dec 8, 2010

Unless I'm mistaken, Bundler can't really function without that hash. It needs to have that hash to be able to distinguish between different Gemfiles that use different shas, tags, or branches from the same repository. Also, end users aren't supposed to use or touch those repositories. Why do you want to remove the hash?

@hedgehog
hedgehog commented Dec 8, 2010

Gemspecs+Bundler are very useful in distributing ruby code and managing the dependencies of that code. One such collection of Ruby code is a Ruby library. But a Ruby library is not the only Ruby code that can leverage and benefit from Gemspecs+Bundler - Chef and Chef cookbooks are another. This is the use case I have in mind.

You are correct Bundler cannot function without this hash unless you can point to a arbitrary, not decorated by ruby_scope, install path (see below).

It needs to have that hash to be able to distinguish between different Gemfiles that use different shas,

Correct, hence suggesting allowing a user to set :overwrite => true to indicate/reaffirm that in the case given Bundler doesn't need to worry about that.

It is not a trivial advantage to be able to use Bundler in both the contexts of writing and deploying the code for a web app (Ruby/Rails), and well as deploying the web app infrastructure (Chef) - one less tool to learn.

So far with my `--install_path' fork I've been able to use Bundler for dependency management of Chef cookbook (via gemspec's). This has allowed me to carve Chef cookbooks from the Opscode and 37 Signals 'silos', see the Cookbooks account on Github.

These two options would help in making Bundler dependency management of Cookbooks relatively painless for existing Chef users. You are right that for many use cases these options would not be used. But having them greatly eases the adoption of Bundler for dependency management of gemspecs, albeit in a non-ruby-library context.

Apologies for the long winded explanation, but it seems important not to have to invent another ruvby-code (gemspec) dependency management solution when introducing these sorts of config options to Bundler would suffice.

@hedgehog
hedgehog commented Dec 9, 2010

Bundler can't really function without that hash.

I've dug into the code a little more and I'd be surprised if Bundler can't function without that hash in the Bundled gem file name. Specifically it is an 11 digit truncation of the full hash.

The full hash is used in decorating the cache folder name, and I don't propose to change that decoration.

the confusing bit right now is that the different hashes are used in the cache naming, cache/bundler/git/<gemname>-<gemversion>-<hash> and the hash used under bundler/gems/<gemname>-<gemversion>-<hash> .

Anyway, the fact that a truncated hash is used in decorating the gem name suggests it might not be earth shatteringly critical - I'll see if the fully spec suite holds up once I've made my changes...

@hedgehog
hedgehog commented Dec 9, 2010

OK so the cache hash is some digest of the URI or some such data - since these digests are one way it can't be playing any function other than ensuring uniqueness.

But it is still weird that, for something that Bundler can't work without, I can't seem to find specs setting out that Bundler is expected to fail without access to this 11 digit hash.

If indeed it turns out this abbreviated hash is needed, just how it is needed will hopefully suggest a way to address providing the missing information - right now I can't see it in the specs.

@indirect
Bundler member
indirect commented Dec 9, 2010

As you've probably noticed, the caches are bare git repos, used as a local mirror to speed up future bundles that include some commit from that repo.

Bundler has, almost entirely, integration specs, not unit specs. That means the vast majority of the internals don't have explicit specs. They are implicitly tested by the correct operation of the bundle command, which is what the spec suite concerns itself with.

@hedgehog
hedgehog commented Dec 9, 2010

Okay so if my changes leave the existing spec suite passing - then they are good to go, and I can issue a pull request by rebasing on the 1.0 stable branch?

One issue is that the existing spec suite (i.e. upstream of my fork) fully passes when it shouldn't (some trivial some not), and I'm currently making these changes to the branch that has the correctly passing and additional pending specs. How much work it is to rebase off the 1.0-stable branch will determine how quickly you see a pull request.

If you want you can look at the chef branch of my fork to see some of what I'm talking about.

@indirect
Bundler member
indirect commented Dec 9, 2010

Since bundler can already manage anything packaged as a gem (with a gemspec), even if it's in a git repository, I'm still unclear on why you want to be able to remove the hashes. The cached git repos are not user-facing, and they are never interacted with directly.

What's stopping you from using Bundler the way it is now to bundle up cookbooks that have gemspecs?

@hedgehog
hedgehog commented Dec 9, 2010

I'm posting a blog entry explains some of this.
http://hedgehogshiatus.com/carving-chefs-cookbooks

@hedgehog

My Bundler fork's Chef branch is now at least usable without any
changes to Chef recipe names (resolving dependencies has been improved
too, still some Bundler bugs remain, and features missing that will be
useful in Chef's context):

http://hedgehogshiatus.com/carving-and-bundling-chef-cookbooks-alpha-2

@hedgehog

Addressed by:
#1029

@mscottford

#1029 claims to close this issue, but this issue is still open, while #1029 is closed. I wondering if this is still an issue or not?

@indirect
Bundler member

Good point. Closing this for now.

@indirect indirect closed this Jan 20, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.