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

[drnic]

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]

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.

[indirect]

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 [email protected] 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:
#2040

[drnic]

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.

[indirect]

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 [email protected] 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:
#2040 (comment)

[drnic]

It might also fix the windows users problems?

[indirect]

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 [email protected] wrote:

It might also fix the windows users problems?

---

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

[tomykaira]

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]

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

[mattetti]

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.

[mattetti]

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).

[indirect]

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 [email protected]
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:
#2040 (comment)

[mattetti]

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" [email protected] 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 [email protected]

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:
#2040 (comment)

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

[xaviershay]

Merging this with rubygems/bundler-features#4