bundle package - include OS specific & pure source .gem files #2040

Closed
drnic opened this Issue Aug 1, 2012 · 13 comments

Comments

Projects
None yet
5 participants

drnic commented Aug 1, 2012

When I run bundle package on a Gemfile with libv8 on my Mac, I get a Darwin specific gem vendor/cache/libv8-3.3.10.4-x86_64-darwin-11.gem. This won't work for me in production.

What might work is that bundle package also added the pure source When I run bundle package on a Gemfile with libv8 on my Mac, I get a Darwin specific gem vendor/cache/libv8-3.3.10.4.gem and/or vendor/cache/libv8-3.3.10.4-x86-linux.gem.

Then, in production (not a Mac), "bundle install --local" could pull out the specific gem it wanted.

drnic commented Aug 1, 2012

The proposed solution does seem to work in production - I added vendor/cache/libv8-3.3.10.4.gem explicitly in parallel to the darwin gems and it installed successfully in production.

Owner

indirect commented Aug 1, 2012

This is a known issue at present -- package is only supported when it is run on the same platform it will be deployed on later. We'd like to fix it at some point, but haven't had time yet.

On Aug 1, 2012, at 9:07 AM, Dr Nic Williamsreply@reply.github.com wrote:

When I run bundle package on a Gemfile with libv8 on my Mac, I get a Darwin specific gem vendor/cache/libv8-3.3.10.4-x86_64-darwin-11.gem. This won't work for me in production.

What might work is that bundle package also added the pure source When I run bundle package on a Gemfile with libv8 on my Mac, I get a Darwin specific gem vendor/cache/libv8-3.3.10.4.gem and/or vendor/cache/libv8-3.3.10.4-x86-linux.gem.

Then, in production (not a Mac), "bundle install --local" could pull out the specific gem it wanted.


Reply to this email directly or view it on GitHub:
carlhuda#2040

drnic commented Aug 1, 2012

If we can agree on the solution - always include the source-only version of the gem with the same version number (if available), then I might look at working on it.

Owner

indirect commented Aug 1, 2012

That seems reasonable off the top of my head. I'd be interested to see how it works in practice.

On Aug 1, 2012, at 12:12 PM, Dr Nic Williamsreply@reply.github.com wrote:

If we can agree on the solution - always include the source-only version of the gem with the same version number (if available), then I might look at working on it.


Reply to this email directly or view it on GitHub:
carlhuda#2040 (comment)

drnic commented Aug 2, 2012

It might also fix the windows users problems?

Owner

indirect commented Aug 2, 2012

I believe it would fix one class of problems that windows users have, yeah. There are at least one or two other common cases that wouldn't be fixed, though.

On Aug 1, 2012, at 5:42 PM, Dr Nic Williamsreply@reply.github.com wrote:

It might also fix the windows users problems?


Reply to this email directly or view it on GitHub:
carlhuda#2040 (comment)

Contributor

tomykaira commented Oct 20, 2012

I encountered similar, but not the same problem.

In order not to fetch gems from production servers, we do bundle package --all on CI server for deployment.
The CI server does not have libraries production servers have, such as MySQL.
Our rails application has mysql2 in Gemfile, therefore bundle package tries to install mysql2 gem, and fails with extension compilation error.

My image of bundle package is just to download gems from rubygems.org and git repositories (we have several private gems), not to install on the CI server.

As @indirect mentioned above, currently bundle package assume that packaging environment is the same as installing environment.

Is there (technical, or desgin related) reason why bundle package installs all gems, not just downloads? Is it hard to change?
If not, I want to approach this issue.

drnic commented Oct 20, 2012

Perhaps run bundle package locally and commit it. That way it's very explicit what you're shipping into CI & production.

Contributor

mattetti commented Apr 26, 2013

Just run into that today and it's quite frustrating :(

When you deploy to Heroku, you don't use capistrano so the only option I guess is to get the linux gem and to add it manually to your vendor folder.

Contributor

mattetti commented May 10, 2013

Talked with @hone about this issue and he suggested to add a command flag to package for a specific platform. This would allow us to bundle package --platform x86-linux or whatever the flag should be named. (suggestions ?)

Technically, I think that the only difference is that bundle package should run targeting the passed platform without deleting packaged gems designed for another platform (OS X for instance).

Owner

indirect commented May 10, 2013

The possible issue here is that it is possible that the lockfile will end up in a hybrid platform state and no longer install correctly. I'm not sure when that happens, though, so it may not here.

On Fri, May 10, 2013 at 5:12 PM, Matt Aimonetti notifications@github.com
wrote:

Talked with @hone about this issue and he suggested to add a command flag to package for a specific platform. This would allow us to bundle package --platform x86-linux or whatever the flag should be named. (suggestions ?)

Technically, I think that the only difference is that bundle package should run targeting the passed platform without deleting packaged gems designed for another platform (OS X for instance).

Reply to this email directly or view it on GitHub:
carlhuda#2040 (comment)

Contributor

mattetti commented May 11, 2013

I talked with @wycats about this issue and he definitely thinks it's a bug.
He also added that adding a platform flag should keep the options in the
bundle file and let us package gems for the deployment and the local one.

I guess someone will need to get a proof a concept so wet can about it
On May 10, 2013 10:28 PM, "André Arko" notifications@github.com wrote:

The possible issue here is that it is possible that the lockfile will end
up in a hybrid platform state and no longer install correctly. I'm not sure
when that happens, though, so it may not here.

On Fri, May 10, 2013 at 5:12 PM, Matt Aimonetti notifications@github.com

wrote:

Talked with @hone about this issue and he suggested to add a command
flag to package for a specific platform. This would allow us to bundle package --platform x86-linux or whatever the flag should be named.
(suggestions ?)
Technically, I think that the only difference is that bundle package
should run targeting the passed platform without deleting packaged gems

designed for another platform (OS X for instance).

Reply to this email directly or view it on GitHub:
carlhuda#2040 (comment)


Reply to this email directly or view it on GitHubhttps://github.com/carlhuda/bundler/issues/2040#issuecomment-17742728
.

Contributor

xaviershay commented Aug 12, 2013

Merging this with bundler/bundler-features#4

@xaviershay xaviershay closed this Aug 12, 2013

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