New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
App generation uses current RVM gemset instead of project-specific gemset #170
Comments
I've tried a few more things to see if I could fix it but with no luck. I've replaced this line with the following (to try switching gemsets a few different ways): # output some debug info
gemset = "#{ENV['MY_RUBY_HOME'].split(/\//).last}@#{app_name}"
say_wizard "set rvm gemset: #{gemset}"
# try setting it the current way
RVM.gemset_use! app_name
# try setting it from running the rvm command
run "rvm gemset use #{app_name}"
# try setting it an alternate way, where gemset = "ruby-1.9.3-p194@my_app"
RVM.use! gemset
# debug the current gemset (a couple different ways) to see if it was set
say_wizard "Using RVM gemset:"
say_wizard RVM.gemset_name
run "rvm gemset name" The output from above when the rails generator runs is:
You can see when |
Finally figured out what's causing this (though I'm still not sure why, as it seems like it should work anyway). It's due to trying to run the rails new my_app -m template.rb command from inside a directory that had it's own .rvmrc and Gemfile (i.e. the directory where I keep my template.rb file under version control). |
In case anyone comes across this (as I just did myself once again while trying to use an updated version of the rails_apps_composer gem), to clarify above, you cannot use the For example, let's say you're using a fork of the What you have to do is compile your fork of the gem locally, do a normal
The above will work as long as you don't have other versions of the rails_apps_composer gem installed, such that you don't need bundler to manage the correct version of the |
Thanks for clarifying this. |
May consider adding something about not using bundler to the "hacking the gem" wiki, if using the project-specific rvm gemset (or I can add it if you'd like). |
Yes, please add a note. Frankly, I don't understand the problem you encountered, probably because I don't understand your use case. Maybe you could explain your use case? What exactly are you doing with the gem that is different from a typical use case? |
Probably partially because I've been trying to explain it from a conceptual point of view. From a programmatic point of view, the issue is with this line: RVM.gemset_use! app_name Let's say that line is in a ruby script called
It won't switch gemsets, because bundler has fixed your current Likewise, if that ruby file is contained within a directory that has a .rvmrc or .ruby-gemset file, and you run the ruby file from within that directory, it also won't work (I'm guessing for the same reason):
So, the only way to get it to work is to run a ruby command from outside any directory that has a .rvmrc or .ruby-gemset file, and run the command directly without bundler:
That's great and all, but what if that ruby file requires a specific version of a gem, e.g. a specific version of the rails_apps_composer gem that I've been working on. A common way to manage this would be to use bundler with a gemfile that says something like: gem 'rails_apps_composer', :path => '~/my_forks/rails_apps_composer'
# or
gem 'rails_apps_composer', :git => 'https://github.com/alfajango/rails_apps_composer', :branch => 'my-feature-branch' And then to run the command with So, the only way to get around it would be to manually compile your locally-modified version of the rails_apps_composer gem, run
Then you can run the rails_apps_composer command without bundler, and it will use your locally-modified, locally-compiled version of the gem. |
To answer your question directly, I was trying to generate a new rails app using local modifications to the gem (before submitting a pull-request) and answering "yes" to the project-specific gemset prompt when generating my new rails app. Doing so causes the creation process to error out due to not having the wrong versions of gems installed due to the gems being loaded from |
So what if you drop |
I don't think the issue is directly from typing Using the rubygems-bundler gem makes it so you don't have to physically type |
In other words, let's say I have a gemset for my rails_apps_composer development, and in that gemset, I have the rails_apps_composer gem installed from rubygems.org. Now, I want to instead use my locally-modified version of the gem. How could I use my version without either using Bundler (or rubygems-bundler if you wish) or locally compiling and installing the gem as described above. |
In my experience, the only way to use a locally-modified version of the rails_apps_composer gem is to create a new gemset, install the required gems (rails, rspec, mg), run |
Yeah, I had missed that when I first started working with the gem, but that's what I was getting at. The bigger point is that the issue described here isn't limited to just building the gem, it's any time you try to use the gem alongside bundler, or from within a directory that has a .rvmrc or .ruby-gemset file. Before trying to develop a forked version of the rails_apps_composer gem, I initially ran into this issue with the rails-composer template using a gemset. The idea was to create a gemset for generating rails apps using the rails-composer template. So, I had a directory with the rails-composer template and a "rails-composer" gemset, using a .ruby-gemset file (or previously a .rvmrc file). My workflow was:
It would error out every time due to not being able to switch gemsets to the new rails app, due to trying to run the command from within the rails-composer-template directory, which had it's own .ruby-gemset/.rvmrc. Instead, I'd have to cd out of that directory, manually switch gemsets (if it wasn't already selected), and then run the
Subtle difference, but took me a while to figure out what was going on and why this was necessary. Of course it started to click when I tried the above using bundler to specify which rails gem version to use and I encountered the same issues of not being able to switch gemsets during the app creation.
To be clear, I don't think this is necessarily an issue that needs to be fixed, but rather that there should probably be a note added to the readme (or maybe to the rails-composer readme) that let's people know not to use the rails composer command with bundler or from within a directory that has a .rvmrc or .ruby-gemset file (whether using Better yet, maybe the rvmrc recipe could detect when the gemset hasn't been switched and alert the user what may be the problem, instead of continuing on and leading to more cryptic errors later on when the wrong gems are loaded during the app generation process. I'm actually working on such a patch now, I'll submit it so you can at least see what I'm thinking, whether or not it gets pulled in. |
Ok, I understand the use case. It sheds light on #114 which reports similar problems. Some kind of exception handling, warning, or error reporting would be great. There are sure to be many people who try a similar use case and don't have the patience, experience, or stamina to troubleshoot to this point. |
Ah yes, this #114 (comment) was almost certainly caused by the gemset not being switched. That's the "more cryptic errors later" I was getting, which I was referring to in my last comment. |
I have not yet been able to get the
.rvmrc
and project-specific gemset from the extras to work. It seems like it's working, but when it gets to the part of the app generation that creates the gemset and switches to it, when I run(where template.rb was created with rails_apps_composer), I see this:
Notice when the generator runs
rvm gemset list
, it shows that it's still using therails-generate
gemset, which is the current gemset, not the app's new project-specific gemset. Sure enough when it's done running, I find that all the gems are installed in my current gemset and the project's gemset is empty and doesn't even contain rails.The text was updated successfully, but these errors were encountered: