Benoit Daloze

The numbers for `ruby --disable-gems` look pretty high to me, maybe you're using rbenv or RVM? For startup measurement it's best to ensure the real ruby binary is already in...

I'm a little bit worried to store this information in the `.gemspec` for two reasons: * It can make the gemspec a lot bigger (a gem can have many files),...

> Default gems don't usually have many files, and we only do this for default gems. Do you really think this can be a noticeable problem? Yes, otherwise I wouldn't...

> By size you mean the size of the file? Yes. It looks like in the `du/ls` output above it's twice the same, I guess a copy/paste mistake. (`ls -l`...

> Sorry, edited. As you can see, only two gemspecs are noticiably affected. But that's only looking by 4KB rounded sizes, which is very imprecise. Also we have to consider...

Regarding the general approach, having a list of all files for default gems feels a bit overkill. The way lazy rubygems deals with this is just assume the gem name...

My main reservation is when looking at the file, and seeing two huge list of filenames it looks quite messy and obvious duplication. I think it'd be nicer to have...

Agreed, I think using `sudo` for installing gems is almost always a mistake. I think most users want to just install wherever it's possible with current permissions, or they actually...

I would think even on macOS installing gems in /usr is almost never (say 99.9%) what one wants. (If one wants to install in system dirs, they can of course...

IMHO `vendor/bundle` as default is better, because it's already established (it is what `--deployment` deploys to by default) and less breaking. I personally don't see sufficient advantages for `.bundle` to...