I've installed REE on CentOS 5 for a very special task (using rails 2.3.10 and ruby 1.8) and I really need it to be isolated
In this case I won't use bundler or smth so.
Everything works ok if I'll setup every gem manually via
/opt/ree/bin/gem install agem
But when I run
/opt/ree/bin/rake gems:install
in prepared for this command project - all (or most, I haven't check every dependency) gems are installed via /usr/bin/gem into common gem path, where I do not need any of them
This is an issue and I do not want to install all gems manually. Have smb ever hit into this issue and probably knows solution?
Solution that really helped me was to temporarily replace /usr/bin/gem with a symbolic link to /opt/ree/bin/gem
With this replacement /opt/ree/bin/rake gems:intall worked as expected - all required gems were installed to REE path - returning /usr/bin/gem to original gem executable made system stable again
This is not very clean solution but it works, so it can be used like hammer in critical situation.
There's either a GEM_HOME variable somewhere in the environment, or the runtime ruby called is not ree. Therefore, I'd suggest at least 3 things to try:
Start with an almost empty environment (run env -i sh for example) and run again the rake command, see if this is still installs gems in the common gem path. Be careful, because env -i is an empty environment, you might see complaints from rubygems (because no HOME or nothing else is set)...
Check that the shebang line (first line of the rake program) really indicates your REE binary and not something else
Finally, do run rake using the REE binary with /opt/ree/bin/ruby /opt/ree/bin/rake gems:install
This should give you an indication of what's going wrong. All in all, I think that the environment issue is probably the most probable culprit of this thing
Related
I have a Linux server, and it has its own Perl whose version is not what I want. So I want to install another Perl on it.
I tried to solve it with Perlbrew, but my server can't download it. It seems like my server does not trust that website address. And I don't know whether I should download it as root. Besides, I think there is a huge difference between root and a normal user to download and install it, and I just want do it as a normal user.
Is there another way install different version Perl on my server?
I downloaded the version I want before, and I tried to install it in a usual way, but it just failed.
Here is the wrong when I tap the command
wget -O - https://install.perlbrew.pl | bash as a normal user.
Maybe I should tap it as root?
And when I try to install the Perl v5.8.8(this is version I want) in ~/bin,i run the Configure.
But I can not run make after that, it just told me that make:No rule to make target , needed by miniperlmain.o Stop.
Besides,
my Linux is Centos 7.4. I don`t how to fix it.
It seems that I find a way to let me to make.
Here is the link.
After I edit the makedepend.SH, I run make again. But I got this wrong:
The thing is really weird. Why Perl V5.8.8 is so difficult to install.
The easy answer is 'just install perl' - it'll drop by default into /usr/local/bin, and you can just use that instead.
DON'T overwrite /usr/bin/perl, as that's a recipe for pain. (Lots of stuff will have dependencies on perl versions installed via your package manager).
I have gone through the following steps:
$ mkdir mongoEg
$ cd mongoEg
$ cabal init
...
Configured to run as an executable. I add mongodb to the build-depends list. I make a dummy Main.hs file and put a basic hello world in there. I then do
$ cabal sandbox init
$ cabal install --only-dependencies
Which responds with:
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: monogEg-0.1.0.0 (user goal)
next goal: mongodb (dependency of monogEg-0.1.0.0)
Dependency tree exhaustively searched.
Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
I read up on other problems people are having, and remove ~/.ghc, remove my mongoEg directory, and repeat to get the same results. I try to run through the analogous steps at http://howistart.org/posts/haskell/1 and find that everything works just fine.
I then guess that something is wrong with the mongodb package itself. I seem to be able to cabal install mongodb in a global environment and use it outside of a sandbox without any issue. So, why wont cabal sandboxes play with the mongodb package?
See this gist for details: https://gist.github.com/anonymous/e5a548cf7d9ec59bea31
After looking here
Cabal configure in a sandbox complains "At least the following dependencies are missing" on installed packages
I saw that the answer states that package names are case sensitive. So I tried changing mongodb to the way MongoDB spells it, namely MongoDB. This did not work, so I tried changing it to mongoDB, and finally there was joy.
So even though I can do cabal install mongodb I can't use that same spelling to install it from within a .cabal file, which is, obviously, completely stupid. I'm sure I'll find the right place to channel my rage about this kind of flagrant violation of the principle of least surprise, but for now I can say that to newcomers it is most needlessly confusing.
I have perl 5.8.8 installed in /usr/bin/perl
I need to use a later version, so am trying to install another version in a different place.
(nb. I started out trying to install perlbrew but on the linux server I'm using but that's not working - am getting all sorts of certificate problems).
I logged in as root and followed the instructions here, to install perl from source:
http://www.cpan.org/src/
This gave me an install of perl in
/root/localperl/bin/perl
I thought that didn't look right so I copied that the localperl directory to /usr
cp -r localperl/ /usr/
Now I can run a script in my /home/myusername/ directory by using
/usr/localperl/bin/perl
So I guess that looks more normal for an alternate install of perl, though:
a) Am not sure this is correct. So the question is if I stick #!/usr/localperl/bin/perl as the first line in every script, will all be fine?
b) Have no idea what to do to install modules for this new version. So:
i) What to do to build latest versions of modules for this version?
ii) Can I copy across all my existing modules that work with 5.8.8?
(Yes, I did attempt to read the doc and saw there were lots of options for configuring the install, but having tried one or two found this was even more confusing). Any specific help on the above appreciated.
I am following along with the sample_app everything runs create and all specs pass until I get to 6.26. As soon as I add the has_secure_password to the User class I receive a Ruby interpreter error that is 1899 lines long. The buffer in vim only shows up to line 600 so I can't even get to the root of the problem. I have verified that I have all of the gems with the correct version numbers. Not sure where to go from here. I am not sure where to start debugging from here. I have made sure to rake db:migrate and rake db:test:prepare. Any help in where to start debugging or direction to take would be great.
Thanks
You're probably missing the bcrypt-ruby gem.
You need to add bcrypt-ruby (~> 3.0.0) to Gemfile to use
has_secure_password:
gem 'bcrypt-ruby', '~> 3.0.0'
This error had nothing to do with Rails Tutorial or RSpec. It ended up being an issue with running guard within a tmux session. Everything works fine if I open a second tab and run guard in a standard terminal.
Currently having a bit of a nightmare trying to run code on another machine. I've been developing a Sinatra app as part of an internship I'm doing. I'm developing on an Ubuntu 12.04 machine, with ruby1.9.3 (through RVM). My supervisor wants to run it on his Debian Squeeze machine, the development server. I listed all the necessary gems in the Gemfile, and pushed up the initial commit. However, we just can't seem to get it running on the Debian box.
Ruby1.8 was initially installed, before my supervisor was aware we'd need Ruby1.9 and up. The Ruby1.9.1-full debian package was installed, but trying to run the Sinatra app with the ruby1.9.1 application.rb does nothing. I added in some print statements to debug it, and the ruby interpreter is reaching the end of the file - the problem is that it is not starting up WEBrick. This exact same code has no problem running on my machine, why is it being so problematic on Debian?
NOTE: Don't suggest switching to RVM. My supervisor is adamant we only use official packages, so it's beyond my control.
I have my Sinatra apps configured a bit differently. That is, I don't run them with ruby application.rb, rather I have a config.ru file with instructions to the Rack middleware. When I want to run my app i just run rackup and the server will start.
The minimal example layout as shown in the Sinatra Readme is as follows.
A basic Sinatra application.rb file:
require 'sinatra'
get '/' do
'Hello world!'
end
and the config.ru:
require './application'
run Sinatra::Application
I don't really know if or how this would make a difference in your situation, but it was the first thing that sprung to mind.
P.S.
Now that I think of it, another thing you could try is to use another server than WEBrick. I think if you add
gem 'thin'
to your Gemfile it should automatically use Thin instead. Remember to re-run bundle install first.