package --all with :path => "../../relative_link"

[wmlele]

I am encountering an issue related to #2494, when trying to package --all and relative links are in the Gemfile.
It only happens when the :path is outside the application and it's going to be missing at the deployment phase. As far as I understand, if it isn't my fault, it is still looking for the non-cached path, breaking the whole point of package --all.

$ bundle --version
Bundler version 1.5.3

---

$ cat Gemfile
source 'https://rubygems.org'

[... rails default Gemfile ... ]
gem 'my_awesome_gem', :path => '../plugins/my_awesome_gem'

---

$ bundle package --all
Resolving dependencies...
[...]
Using my_awesome_gem (0.3.2) from source at /Users/lele/Documents/Develop/Shared/myapp/vendor/cache/my_awesome_gem

---

$ mv ../plugins/ ../plugins-
(or deploy on production server)

---

$ bundle install --deployment
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.

You have added to the Gemfile:
* source: source at ../plugins/my_awesome_gem

You have deleted from the Gemfile:
* source: source at vendor/cache/my_awesome_gem

You have changed in the Gemfile:
* my_awesome_gem from `source at ../plugins/my_awesome_gem` to `no specified source`

[indirect]

I'm not sure if package --all supports path gems. IIRC, path gems are always left entirely alone and managing them is just up to you.

On Tue, Feb 25, 2014 at 2:45 AM, Lele Forzani [email protected]
wrote:

I am encountering an issue related to #2494, when trying to package --all and relative links are in the Gemfile.
It only happens when the :path is outside the application and it's going to be missing at the deployment phase. As far as I understand, if it isn't my fault, it is still looking for the non-cached path, breaking the whole point of package --all.

$ bundle --version
Bundler version 1.5.3
---
$ cat Gemfile
source 'https://rubygems.org'
[... rails default Gemfile ... ]
gem 'my_awesome_gem', :path => '../plugins/my_awesome_gem'
---
$ bundle package --all
Resolving dependencies...
[...]
Using my_awesome_gem (0.3.2) from source at /Users/lele/Documents/Develop/Shared/myapp/vendor/cache/my_awesome_gem
---
$ mv ../plugins/ ../plugins-
(or deploy on production server)
---
$ bundle install --deployment
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
You have added to the Gemfile:
* source: source at ../plugins/my_awesome_gem
You have deleted from the Gemfile:
* source: source at vendor/cache/my_awesome_gem
You have changed in the Gemfile:
* my_awesome_gem from `source at ../plugins/my_awesome_gem` to `no specified source`

---

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

[wmlele]

In the example ../plugins/my_awesome_gem is the base directory of a gem project, including a my_awesome_gem.gemspec, in a similar fashion to what you would expect from a :git or :github source. What strikes me as an inconsistency is:

1. my_awesome_gem gets packaged into vendor/cache, as mentioned by the output of package --all, along with regular gems and :git sources.
2. Gemfile.lock correctly has vendor/cache/my_awesome_gem as source
3. The exact same my_awesome_gem would be correctly packaged and deployed if the original (ie: before packaging) source was :git .

[vihai]

:path during packaging should only be one of the many sources from where to retrieve the gems.
I'm using :path because I have tens of custom gems that should be packaged when deploying the application.

After the bundle is made they should behave like the other gems. IMHO bundler is misbehaving in this respect.

[indirect]

It sounds like this is a bug in path. If the cache contains and the lock points to vendor/cache/my_awesome_gem, Bundler should use it.

[vihai]

Closed because a patch has been committed or because this bug became a "feature" ?

[indirect]

Asking if this bug became a "feature" is totally unwarranted. Just ask your question, don't be mean about it.

My last comment was never responded to by anyone, so it's not even clear if this is a current bug. Are you still having this issue? If you are, feel free to patch it or let us know it's still a problem.

[TimMoore]

To be honest, I'm not sure how this even could work without violating someone's expectations about how Bundler works.

Let's say bundle package --all packaged a path gem into vendor/cache. Then, does that mean that Bundler runs the gem that's inside vendor/cache rather than the one at the original path location? What happens if you update the gem in the original location and start your app without running bundle install again? Right now, Bundler picks up the change, but if it were running the version copied into vendor/cache, it wouldn't.

On the other hand, if it always runs from the original location, Bundler can no longer make the guarantee that you're running the same code in development and production when you put the packaged code onto another machine, because you may not have re-packaged the gem after changing it in the original location. With git gems, it locks to a commit hash, but with path gems, there's no checksum or anything else happening, so it just runs whatever is there. AFAIK, the path feature was intended to be used on gems already vendored inside the project directory. Using it on an external path totally breaks Bundler's promise.

I agree that there's a bug here, if the behaviour originally described is still happening, but it's not clear at all to me how to resolve it.

In any case, this is a duplicate of #2175.