Almost all my projects are non-Rails projects --just plain Ruby gems. And in every one of those my Gemfile is exactly the same.
I'm sure that's common for other gem developers too.
So, I was thinking it would be great if Bundler would simply assume the above if no Gemfile is found but a gemspec is.
I suggest using bundle init --gemspec to create the simple Gemfile you mention. In order to function when invoked from subdirectories of a bundled project, Bundler recurses up the directory tree looking for a Gemfile. Assuming a Gemfile would change that behaviour in an inconsistent way, so I'm reluctant to make such a change.
bundle init --gemspec
I hear you. I deal with the same ascending search in a number of my tools too --and they don't have a special config file to cling to either. I worked out the searching for .git, .hg or _darcs is going to cover most cases. Basically you can just allow for the default in those cases, otherwise Gemfile is required.
What's problem of using just *.gemspec when exists? Is that because you have not specified source?
So essentially we will have to recursively search for either .gemspec file or Gemfile. Also relying on presence of a .gemspec file will then become external interface of Bundler, which in turn means if someday Rubygems decide to change their gemspec extension this won't work. Currently when I specify gemspec in Gemfile how it resolves the corresponding gemspec is internal to Bundler.
My 2 cents on this matter I think it is more trouble than worth.
@gnufied I agree that it's more trouble than it's worth.