Why doesn't the Heroku client CLI work under Capistrano? - capistrano3

I have a Capistrano deployment that needs to get the database URL (using the deploying machine, not the target) by calling Heroku toolbelt with Ruby backticks, viz heroku pgbackups:url --app strong-galaxy-5765. I have done this under Capistrano 2 for months, but now, after upgrading to Ruby 2.2 and Cap 3, calling the heroku command using Ruby backticks within the Capistrano task produces a blank string. And it's not just this particular command: even 'heroku --version' returns nothing.
Data points:
* standard shell commands are back-tickable and produce appropriate output
* The behavior is identical if I give an absolute path to the 'heroku' command.
* whoami reveals that the user under the Capistrano task is me.
* all heroku commands that I've tried in a generic Ruby script with backticks work fine.
* Everything worked fine until I switched to Capistrano 3 and Ruby 2.2
So there must be something about the Capistrano environment, and I'm climbing the walls trying to figure out what it would be. One possible clue: I get the following error output from my Capistrano task when running the 'heroku' command:
/Users/upstill/.rvm/gems/ruby-2.2.0#global/gems/bundler-1.7.12/lib/bundler/definition.rb:380:in validate_ruby!': Your Ruby version is 1.9.3, but your Gemfile specified 2.2.0 (Bundler::RubyVersionMismatch)
from /Users/upstill/.rvm/gems/ruby-2.2.0#global/gems/bundler-1.7.12/lib/bundler.rb:118:insetup'
from /Users/upstill/.rvm/gems/ruby-2.2.0#global/gems/bundler-1.7.12/lib/bundler/setup.rb:17:in <top (required)>'
from /usr/local/heroku/ruby/lib/ruby/1.9.1/rubygems/custom_require.rb:36:inrequire'
from /usr/local/heroku/ruby/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
INFO 'heroku pgbackups:url --app strong-galaxy-5765'
=> (pid 46786 exit 1)
Note: my Ruby environment is 2.2.0, as shown by ALL OF my Gemfile, :rbenv_ruby in the Cap deploy.rb file, rvm, rbenv and 'ruby -v'. Everything else Capistrano does uses the 2.2 environment. But 'heroku --version' reveals that IT is built for 1.9.3. I would love to build it for 2.2, but running the installer again in the new environment did nothing to change the Ruby spec.
Okay, so this is my dead end. Any help would be desperately appreciated.
Thanks,
Steve

install the toolbelt via homebrew instead
$ brew install heroku

Related

extJs 7.0.0 Community Edition - install docs not working

I'm on mac.
Following the guide here: https://docs.sencha.com/extjs/7.0.0-CE/guides/getting_started/mobile_desktop_application/getting_started_with_npm.html
I signed up for to the community edition, received the mail, created my sencha.myget.org account, and did the following commands successfully in a terminal:
step 1: login to npm repo
npm login --registry=https://sencha.myget.org/F/community/npm/ --scope=#sencha
step 2: install app generator cli
npm install -g #sencha/ext-gen
step 3: generate the app
ext-gen app -a
Now step 4 (run the new application) is where I have a problem:
cd my-app
npm start
Gives me this error:
If I open the log I can see the exception message:
/Users//Desktop/test/extjs/my-app/node_modules/#sencha/cmd/dist/plugin.xml:378: The following error occurred while executing this line:
/Users/me/Desktop/test/extjs/my-app/build.xml:15: Unable to create javax script engine for javascript
What am I doing wrong?
So this is how I did it on mac 10.14.
Ok, so reading about javax, apparently it was used in java se8 (https://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngine.html).
So, I downloaded it using this website: https://adoptopenjdk.net/,
and more precisely this page: https://adoptium.net/?variant=openjdk8.
Once downloaded, I had multiple versions of java installed on my computer and so I had to switch to that one.
So I learned how to switch to any java versions.
First to display the existing versions, type this in the terminal:
/usr/libexec/java_home -V
Then to change version:
export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
(notice that for the version number you just type the first two digits, not the whole version number )
To check that it worked:
java -version
Once java 1.8 (apparently that's the version name for jdk8) was running, the npm start command worked without errors.
You need to downgrade Java to any version less than 15, because the Nashorn JavaScript Engine had been removed, which it depends upon. Downgrading Java as far as version 8 probably isn't the optimum (in particular, when also using it for Java development).

Terminal issues error message that no Django module "models" exists, but it is in the directory

I'm a motivated beginner working my way through Python Crash Course. I created a project and an app using Django. I'm unable to get the python manage.py run server command to work. This is the header of the long error message:
"Watching for file changes with StatReloader
Exception in thread Django-main-thread".
The middle includes several lines of "".
At the end, it says "from models import Activity"
"ModuleNotFoundError: No module named 'models''
There IS a module named models in the directory. This is my second exercise using Django, and the program worked earlier. I've searched the net and read everything remotely similar, but have been unable to find a solution. How can I make the program recognize a module that is there?
I think the problem was that the version of pip in the virtual environment was the python 2.7 version instead of the 3.9 version I used to create the project. It had to be upgraded using:
python3 -m pip install --upgrade pip
I also used python3 for the manage.py runserver command instead of just python.

Change mod_wsgi from python3.5 to 3.6

I have a flask app that used to run with python3.5 on apache2.
I am now trying to change it to run on 3.6 (i have sone type hinting in my code that is only supported on 3.6).
I have installed the module for python3.6, but when tried to restart apache and run my app, it fails.
When running
mod_wsgi-express module-location
I have the python3.5 version
/usr/local/lib/python3.5/dist-packages/mod_wsgi/server/mod_wsgi-py35.cpython-35m-x86_64-linux-gnu.so
The same file also existis on my server in python3.6 dir.
I also changed my $PATH to run python3.6 as a default for python.
How can I tell apache to run on python3.6 and not on 3.5?
WOHA! It's working!
I uninstalled the mod_wsgi (sudo apt get remove libapache2-mod-wsgi).
Then, Installed the module via pip specifically to python3.6 (python3.6 -m pip install mod_wsgi), but at this point the apache still ran python3.5.I added to the apache configuration file (in ubunutu 16.4 the file is located at: /etc/apache2/apache2.conf and /usr/local/lib64/python3.6/site-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so for RHEL/CentOS 7) the followings:
LoadModule wsgi_module "/usr/local/lib/python3.6/dist-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so"
and
WSGIPythonHome "/usr" and that did the trick.
I weeped a lot of tears over this issue, finding the apache2.conf file etc, so hopefully this will be helpful to anyone.
The LoadModule solution worked for me. However, I found it easiest to first ensure
a2dismod wsgi as provided by the default apache2 module. I spent 3 days looking at various solutions and answers and reviewing Graham's WSGI guide.
What I did in my case is was to remove python 3.6 from Django env and re-install python 3.5 and it worked.

Python behave running from python2.7 rather than python3.4

When I run behave it seems to run from python2.7 and fails to find selenium, which is installed for python3.4. Do I need to configure behave to run python3.4 somewhere - I can see nothing on the behave site, or elsewhere. There are posts about using behave with python 3.4, so it is possible.
Here is what I see:
$ behave
...
File "/usr/local/lib/python2.7/dist-packages/behave/runner.py", line 304, in exec_file
exec(code, globals, locals)
File "features/steps/home_page.py", line 2, in <module>
from selenium import webdriver
ImportError: No module named selenium
I have PYTHONPATH pointing to python 3.4/dist-packages:
$ echo $PYTHONPATH
/usr/local/lib/python3.4/dist-packages
$ ls /usr/local/lib/python3.4/dist-packages/selenium
common __init__.py __pycache__ selenium.py webdriver
I have behave installed in both /usr/local/lib/pythonX.X/dist-packages where X.X is 2.7 and 3.4
Any help much appreciated.
If you install behave for Python 3.x and Python 2.7 each installation will install the script that starts Behave at the /usr/local/bin/behave location. Whichever is installed last will win the conflict because it will overwrite the other's file. (The files that go in /usr/local/lib/python<version>/dist-packages will be fine because <version> is different in each case.)
One way to fix this is to settle on installing Behave only on Python 3. Uninstall the Python 2.7 version and reinstall the Python 3 version, and it should work.
If you do need both versions for different projects then you should use virtualenv to create Python installations for the various projects you are working on. This is what I've settled on for my own projects.

sunspot with jruby

Hi can sunspot be used with jruby, also here is my app details
jruby-1.6.1
rails 3.0.7
when i install all the gems and run rake sunspot:solr:start it gives me the following error
Gem::LoadError: Could not find RubyGem sunspot (>= 0)
report_activate_error at /Users/dpatel/.rvm/rubies/jruby-1.6.1/lib/ruby/site_ruby/1.8/rubygems.rb:861
activate at /Users/dpatel/.rvm/rubies/jruby-1.6.1/lib/ruby/site_ruby/1.8/rubygems.rb:255
gem at /Users/dpatel/.rvm/rubies/jruby-1.6.1/lib/ruby/site_ruby/1.8/rubygems.rb:1215
(root) at /Users/dpatel/.rvm/gems/jruby-1.6.1#solr/bin/sunspot-solr:18
However when I run rake sunspot:solr:run, it works fine.
Also, when i search using Model.search, it works fine, but I when I fire up solr webapp on the browser and search something, it does not work.
Can anyone tell me what is happening, new to sunspot.
-Thanks
Hi i kinda figured it out, i am on jruby and fork is not allowed on jruby, and rake sunspot:solr:start tries to fork and thrown out an error but
rake sunspot:solr:run starts solr in the foreground and works fine, a little painful but all is well :-)
-D
You already figured out the forking issue, so if you want to stay in a single shell for development and testing I found these aliases to be particularly useful for running sunspot in a particular rails environment and then finding and killing that process when I am done:
If you keep the default ports:
alias sunspot_run_test="RAILS_ENV=test sunspot-solr run &"
alias sunspot_kill_test="fuser -n tcp 8982 -k"
alias sunspot_run_dev="RAILS_ENV=test sunspot-solr run &"
alias sunspot_kill_dev="fuser -n tcp 8982 -k
If you change ports you will need to change the auto-generated sunspot.yml or put a sunspot.rb in config>initializers and you can add a -p{$port_num} before the & on the run aliases and change the explicit port numbers to {$port_num} for the kill aliases.
As Vlad mentioned, it's hard to know what's going on with in the browser from your explanation. One thing that can catch you if you are new to sunspot is that you need to have an instance running in dev environment (use the sunspot_run_dev alias) before you try to CRUD anything in your database or you will get an connection refused error.
See bash aliases not recognized by a bash function: sunspot_rails, jruby, rspec for some more troubleshooting with functions to wrap commands that require sunspot.
For rake issue:
gem install sunspot -v 1.2.rc4
For 'does not work in browser': what do you mean it does not work?
if no result is returned:
You can debug it by comparing Solr requests made by you manually on script/console and the ones made by the server. By default, the sunspot gem logs requests in 'logs/sunspot-solr-development.log'
error (which?)

Resources