Deployment fails when using paths in Gemfile

[wildchild]

gem "my-gem", path => "../../my-gem"

after running bundle package --all && bundler install --local Gemfile.lock contains new path -- "vendor/cache/my-gem"

Gemfile still contains old path as expected.

bundle install --deployment will end with:

You have added to the Gemfile:
* source: source at ../../my-gem

You have deleted from the Gemfile:
* source: source at vendor/cache/my-gem

You have changed in the Gemfile:
* couchrest from `source at ../../my-gem` to `no specified source`

Is it normal behavior and I must edit paths in Gemfile on deployment?

[indirect]

@josevalim, I thought package was only supposed to cache git gems, not path gems?

On Nov 21, 2012, at 8:35 AM, Alexander Uvarov notifications@github.com wrote:

gem "my-gem", path => "../../my-gem"
after running bundle package --all && bundler install --local Gemfile.lock contains new path -- "vendor/cache/my-gem"

Gemfile still contains old path as expected.

bundle install --deployment will end with:

You have added to the Gemfile:

• source: source at ../../my-gem

You have deleted from the Gemfile:

• source: source at vendor/cache/my-gem

You have changed in the Gemfile:

• couchrest from source at ../../my-gem to no specified source
  Is it normal behavior and I must edit paths in Gemfile on deployment?

�
Reply to this email directly or view it on GitHub.

[wildchild]

@indirect, this will make life harder.

[josevalim]

Well, if --deployment is moving the gem from one place to the other, that is obviously bug that needs to be fixed.

Another discussion though is if package should package paths and my answer would be yes. Maybe we can support something like package: false, but again, that's another discussion.

@wildchild can you provide a failing test case? You should find it easy to write one in case you haven't written any yet.

[indirect]

@josevalim, if package packages path gems, then it's definitely moving them from one place to another. If packing path gems is what we want, we'll need to override the frozen check for path gems to allow packaged ones.

On Nov 21, 2012, at 9:39 AM, José Valim notifications@github.com wrote:

Well, if --deployment is moving the gem from one place to the other, that is obviously bug that needs to be fixed.

Another discussion though is if package should package paths and my answer would be yes. Maybe we can support something like package: false, but again, that's another discussion.

@wildchild can you provide a failing test case? You should find it easy to write one in case you haven't written any yet.

—
Reply to this email directly or view it on GitHub.

[wildchild]

@josevalim, before I fall into writing specs, can we clarify desired behaviour?

Just to be clear,

1. After bundle package --all Paths to gems in Gemfile.lock are the same as in Gemfile. Is it ok?
2. If I run bundle install --local (after bundle package --all) paths in Gemfile.lock altered to vendor/cache/GEM_NAME. Is it ok? Shouldn't bundle update paths after first step?
3. Now it's time to push and pull changes on deployment machine. Well, bundler shouldn't yell about path mismatch in Gemfile and Gemfile.lock. I believe this is simple solution.

By the way, if 1st and 2nd steps are ok, it seems weird that developer must install cached for deployment gems locally just to make this deployment possible (to alter paths in Gemfile.lock).

Shouldn't bundler alter path in 1st step and than just ignore path mismatch?

[josevalim]

I am not sure if bundle package --all should change the paths in the Gemfile.lock. Does the path change for git repositories?

[wildchild]

@josevalim, bundler does not change anything for git at all. I guess it behave absolutely differently in this case.

I am wondering why not just bundler build gems for both git and path specs and copy it to vendor/cache just like for regular gems does.

[josevalim]

@wildchild so I don't think we should change the Gemfile.lock at all. We should just check if there is something in the cache and use it.

I believe building the gems would be too error prone but that is up to discussion. /cc @wycats

[wildchild]

I don't think we should change the Gemfile.lock at all

I think the same. By the way, it changes. It's a related issue.
I'll try to spend this weekend to make a patch for both, but I totally unfamiliar with bundler, never hacked it before. Would be cool to fix it before release.

[josevalim]

Nice! If you haven't ever played with Bundler, I would recommend you to
start with the test case. You will find it very easy and convenient to
write. Then, in case you can provide a fix, just upload the test case and I
can try to fix it myself. :)

[wildchild]

@josevalim, I pushed 2 specs.

After some investigation I suspect that there are much more problems with path. Bundler behave differently if there is a dependency in a .gemspec of a gem specified as a path gem. For example, this spec 7b7c227 passes unless dependency is specified.

[wildchild]

Guys, does these failing specs make sense? If so, could anyone show me the right way? I looked through the sources and I can't imagine where Gemfile.lock gets updated path vendor/cache.

[josevalim]

Interesting. I am wondering if maybe we should kill --all and provide --include-git instead. Or we override the frozen check, as proposed before. @indirect, wdyt?

[wildchild]

Any status update?

Or we override the frozen check, as proposed before.

Much better than run and hide from a problem.

[indirect]

I think that the specs make sense, and I think the correct solution is probably to override the frozen check. I just haven't had time to work on it yet, sorry.

[indirect]

After spending some time investigating this, I now think the correct solution is to update the Gemfile.lock with the cache path during the package --all command. Hopefully I'll have time to implement that soon.

[kowal]

Hi

I've just run into this. Gems specified via :path aren't vendored by bundle package --all.

Docs say:
"--all: package :git, :path, and .gem dependencies. Once used, the --all option will be remembered."

Does it really make sense to use gems from "path" locations and then package them in vendor/cache to be used in bundle --local or --deployment scenarios?

Or maybe instead I should simply add those gems manually to vendor/cache and in Gemfile specify them without path. But then - what happens when someone on other machine runs bundle install without --local?

[thedanbob]

I've also had to deal with this. bundle package --all adds the gem directory to vendor/cache, Gemfile.lock gets updated with the vendor/cache path, but running bundle install --deployment on the server gives me the same error as in the original report.

As a workaround, I changed the line in my Gemfile to this:

gem 'shared', path: Pathname.new('../shared').exist? ? '../shared' : 'vendor/cache/shared'

[coilysiren]

This issue is open for anyone to start working on a PR for

[allenzhao]

I'm working on it;)