Does Bundler have to be installed so that singularity.gs can be installed? - singularitygs

do you have to have Bundler installed to install singularity.gs or can you install like on the video on Viemo?

While you don't need Bundler per se, it is highly recommended that if you are working in any Ruby stack that you use Bundler to ensure that your gem dependencies are locked in place and you don't run into incompatibility issues across gem updates or across team. When singularity 1.2.0 gets a full release, you'll be able to drop the Singularity Sass straight into your project and not need the gem, but if you are compiling with the Ruby compiler it's still recommended to use Bundler.

Related

Bundler version for Ruby 2.3.8?

I currently have 2 ruby versions, 2.5.5 and 2.3.8, I am managing them with rbenv, and for gems, I use bundler to manage my specific gem versions. I have an issue when I want to switch to a project that uses 2.3.8 or a version that has to do with Ruby version 2.3.
My question is how do I get bundler to run the command to bundle install interact with my 2.3 projects.
My current version of bundler is 2.0.2.
I have already tried installing a lower version of bundler of which the bundler website claims to interact with ruby version 2.3.
I thought that if I specified the command to run bundle _version_ install it would work, but it still gave me the response that it needed ruby version 2.5 for bundler to work.
Lots of help appreciated.
In some situations, isolation can help. I would like to recommend rvm (https://github.com/rvm/rvm) for managing ruby versions. This tool is very similar to rbenv but in comparison, it allows you to create gemsets which are kind of containers of gems for special purposes. For instance:
rvm install 2.5.5 --disable-binary
rvm use 2.5.5#name-of-gemset --create
gem install bundler
bundle install # inside your project folder with Gemfile
I think that you will not have problems with versions again.

rubygems automatically updating on install

I am currently managing an installation of ruby 1.9.3 in red hat 5.
I have found that, during a specific gem install, ruby is trying to download and install the latest version of a particular required gem.
I have attempted to prevent the updating of gems using the --conservative flag, however, this does not seem to work.
The gem in question requires a specific version of launchy which, in turn, requires a specific version of addressable.
The versions of these gems that are already installed meet the requirements of the gem I am attempting to install. However, the gem command attempts to download and install the latest version of addressable.
This is a problem, because the latest addressable requires public_suffix, which only installs in ruby 2.x and greater.
The gem that I am trying to install is a custom gem, and thus I have modified the gemspec, and found that removing the launchy requirement fixes the issue. However, launchy is a required gem, so the requirement needs to stay in the dependency list.
Has anyone had any experience with dealing with this particular version of ruby and gem and found issues with dependencies?
I have tried going in and modifying gemspec for launchy and addressable in the installed gems dirs, but have found that the issue is with the gem install command attempting to update/install the latest gems despite giving it flags telling it otherwise.
ruby 1.9.3
gem 1.8.23
After some additional research prompted by the above responses, it was determined that an outdated version of Hoe was causing the generated gem to try and install the latest dependencies. After moving away from Hoe to manage dependencies and versions, my issue has been solved.
Some of the dependency management classes seem to behave quite differently, so that's probably the first place to look.
Use the -v flag to specify the exact version to install:
gem install your-custom-gem -v 1.1

Explain the differences in setting up a web dev environment on Mac

I'm new to web development and as I research how to install various dev tools on my Mac the following questions have come up,
Should I install Heroku via the standalone toolbelt or via homebrew?
Isn't the point of homebrew to manage non-Apple packages in a single place.
Ruby development using the bundler gem again seems like a wise decision, so that gems are no longer installed via gem install but rather with a project Gemfile. This would suggest that the only gem install required is Bundler. However, then I see developers install a range of tools like this
gem install bundler foreman pg rails thin --no-rdoc --no-ri
Is this just laziness or is there some reasoning behind this choice that I don't understand?
bundler and foreman I understand being outside of the project. Bundler for obvious reasons, and foreman because sometimes it doesn't like to run in the constraints of the bundle very well, but to my knowledge there is no reason to install pg, rails, and thin outside the bundle.
In certain bundler configurations, bundler will check for locally installed gems and use them as part of the bundle, while in others, it does not. Perhaps the reason for installing that suite of gems is to prevent multiple versions of the gem being installed in different projects on the system, essentially acting as a global repository of gems.
In all honesty, I'm brainstorming on this one, but its the only logical explanation I can come up with, hopefully someone can answer this better than myself.

How to switch compass version?

I have two versions of Compass, 0.12 and 0.13.alpha. The default version is 0.13.alpha but sometimes I need to switch to 0.12.
What command will permit this, please?
old topic, but I just came across the issue of having 2 projects. one using compass version 0.12 and the other 1.0.
as the newer version of compass relies on a new major release of sass, many deprecation warnings and compatibility issues are experienced when trying to run the newer compass on the old project.
well, now to the solution:
ruby gems already support having multiple versions installed. and after taking a look into the compass executable, it turns out there is a way to specify which compass version to use (the file is generated by rubygems, see http://pastebin.com/HeZnE0T5 if you are curious)
with that we can now have multiple versions of compass installed at once. eg:
gem install compass -pre // currently version 1.0.0.alpha.19
gem install compass // currently version 0.12.6
and now we can use them by specifying which version to use:
$ compass version
Compass 1.0.0.alpha.19
Copyright (c) 2008-2014 Chris Eppstein
Released under the MIT License.
Compass is charityware.
Please make a tax deductable donation for a worthy cause: http://umdf.org/compass
$ compass _0.12.6_ version
Compass 0.12.6 (Alnilam)
Copyright (c) 2008-2014 Chris Eppstein
Released under the MIT License.
Compass is charityware.
Please make a tax deductable donation for a worthy cause: http://umdf.org/compass
this obviously also works for other compass commands, eg watch:
$ compass _0.12.6_ watch .
>>> Compass is watching for changes. Press Ctrl-C to Stop.
EDIT: of course the version switch can be done in a Gemfile, but in my case its not a ruby project and compass is started via command line
If you are switching versions for different projects, I recommend using either RVM (Ruby) or virtualenv with some help (Python) or something similar to manage gems and versions. Bundler will help make either solution simpler to maintain.
If you are switching versions within a project, I recommend reconsidering your approach.
This is really simple using bundler.
Install bundler:
$ gem install bundler
Create the Gemfile in your project if you don't already have one:
$ bundle init
Specify the version you want/need in your Gemfile:
gem 'compass', '~>0.12.2'
gem 'sass', '3.2.8'
Install the specific gems and dependencies you have defined in your Gemfile:
$ bundle install
When executing a gem, you can now use bundler to control which version to execute based on your Gemfile:
$ bundle exec compass watch
That's it!
It's helpful to leave a comment in your Gemfile telling other developers how to use bundler:
# Now that you're using Bundler, you need to run `bundle exec compass watch` instead of simply `compass watch`.
Read more about versioning at http://bundler.io/v1.6/gemfile.html
Change the gemfile, add in a version parameter.

Capybara-1.1.1 conflicts with capybara (~> 0.4.0)

I updates my gems, now I get this error:
Unable to activate capybara-mechanize-0.2.7, because capybara-1.1.1 conflicts with capybara (~> 0.4.0) (Gem::LoadError)
I've googled and searched SO, but I'm a bit of a n00b and not really sure what I need to do next.
Thanks for your time,
Mike
You can try to delete conflicting gem by invoking gem uninstall capybara. You will be the prompted which version to delete.
To remove all old gems in one swipe just use gem cleanup.
After cleaning old version which, hopefully, you don't need you should be ok. Otherwise, consider using bundler (http://gembundler.com/) to manage gems in your projects and RVM, where you can have completely separate gemsets.
My general workflow is as follows:
In Rails/Sinatra etc applications I put vendor/cache in my .gitignore and run bundle pack which installs gems into that directory. That way I can keep installed gems local per application.
In my daily workflow I use RVM to switch ruby versions and install gems into gemsets which I can port across RVM rubies. http://beginrescuened.com. A popular and more lightweight alternative to RVM is https://github.com/sstephenson/rbenv.
So bundler manages my gem dependencies in a sane manner and RVM lets me manage gems at a granular level. I went through the dependency hell of plain old rubygems a while back, never again.
You've either got two versions of Capybara installed (both 1.1.1 and some other version). You can go a gem list --local (or if you're using Bundler do a bundle show) and uninstall one of them.
Or possibly you've specified that you want versions ~> 0.4.0, and the version number 1.1.1 is out of that range. That is, the specified version range ~> 0.4.0 will only work with 0.4.0 .. 0.4.x, and not 0.5.x or higher.

Resources