Configuration is controlled through a file called
.env in the base
directory. This jives with how Heroku manages configuration variables;
.env is just an environment variable if you really want to
manage things yourself, but using Heroku tools makes sure you run like things
do in production.
First, get the Heroku toolbelt.
.env. If all you want to do is run Pyret code
and test out the REPL, you only need to edit a few variables. If you want to
use the standalone pyret that comes with the checkout, you can just set
Then you can run
$ npm run local-install $ ln -s node_modules/pyret-lang pyret $ npm run build
and the dependencies will be installed.
To run the server (you can let it running in a separate tab -- it doesn't need to be terminated across builds), run:
$ npm start
The editor will be served from
$ npm run build
and then refresh the page.
Running with Development Pyret
If you'd like to run with a development copy of Pyret, you can simply symlink
pyret elsewhere. For example, if your development environment has
pyret-lang both checked out in the same directory, you
could just run this from the CPO directory:
$ ln -s ../pyret-lang pyret
Configuration with Google Auth and Storage
In order to have share links, saving, and other docs-related functionality
work, you need to add to your
.env a Google client secret, a client ID, a
browser API key, and a server API key. You'll copy
.env, and populate several from your dashboard at Google.
At https://console.developers.google.com/project, make a project, then:
GOOGLE_CLIENT_SECRET, which are used for authenticating users:
Credentials -> Create Credentials -> OAuth Client Id
http://localhost:5000and the redirect URI to
GOOGLE_API_KEY, which is used in the browser to make certain public requests when users are not logged in yet:
Credentials -> Create Credentials -> API Key -> Browser Key
Again, you should use
http://localhost:5000as the referer for development.
Add the Google Drive API to your project and include the Google Drive API Scopes in your OAuth consent screen.
For Google accounts to work locally, you'll also need to run a local Redis instance and put its connection url into the
Testing with Selenium
There are tests in
test/ that use Selenium to script a
The instructions for setting up Selenium to open Chrome locally are somewhat platform-specific. You will need chromedriver to be on your path. Then run running:
npm install selenium-webdriver mocha npm run mocha
with Selenium and mocha installed and a development server running. You can refine this with, e.g.
npm run mocha -- -g "errors"
to only run the tests in
test/errors.js. (The extra
-- are to escape the
portion of the options to pass to the underlying
Another options to run all the tests on Sauce Labs (https://saucelabs.com). You can also get a personal free account with unlimited testing if you only test open-source stuff (which Pyret/CPO are). Sauce also stores screencasts and logs of your tests, which can be helpful with debugging.
First, add your sauce username and access key (from your account page at
(Not my real access key)
Second, install the Sauce Connect client for your system from https://docs.saucelabs.com/reference/sauce-connect/. Follow the instructions for starting the server (the default configuration should work fine), using the same username and access key, for example, on Ubuntu I run:
~/sc-4.3.9-linux32$ ./bin/sc -u gibbs -k deadbeef-2671-11e5-a6a1-206a8a0824be
That sets up a tunnel to Sauce Labs, and on the same machine you should now be able to run:
$ heroku local:run ./node_modules/mocha/bin/mocha
To run only a particular file, pass in one of the filenames in
$ heroku local:run ./node_modules/mocha/bin/mocha test/world.js
Check out how
image.js are written: they look up files from
test-util/pyret-programs and run them according to Selenium testers in
test-util/util.js. The best way to test a whole new library is probably to
add a directory here and figure out a good predicate that can be applied
across the files (
runAndCheckAllTestsPassed is probably a good candidate for
many use cases).
Setting up your own remote version of code.pyret.org with Heroku:
If you are doing development on code.pyret.org, it can be useful to run it on a remote server (for sharing purposes, etc.). Heroku allows us to do this easily.
Before you begin:
Make sure you have cloned the code.pyret.org git repository. Then follow the instructions to get it running locally.
The Heroku getting started guide is helpful, but it will be easier if you set things up in the order below https://devcenter.heroku.com/articles/getting-started-with-nodejs
To run remotely:
- Make an account at http://heroku.com/ and from a terminal run
- Navigate to your local code.pyret.org repository in a terminal.
heroku create <appname>. This will create an app on Heroku linked to your local repository.
- Set the config variables found in
.env.example) on Heroku. You can enter them using
heroku config:set NAME1=VALUE1 NAME2=VALUE2or in the online control panel. There are 3 config variables you should pay special attention to:
- add key
GIT_BRANCH, value should be your branch name
- add key
GIT_REV, value should be your branch name
PYRETfrom local host to a URL that points to cpo-main.jarr from build folder. Make sure URL ends in js instead of jarr.
Add a Redis Cloud database using
heroku addons:add rediscloudor at addons.heroku.com. You will likely have to verify first (enter a credit card), but you shouldn’t actually be charged for the most basic level (but check for yourself!).
Now, still in your code.pyret.org repo, run
$ git push heroku <localbranch>:master $ heroku ps:scale web=1
heroku openor visit appname.herokuapp.com.
Tips for redeploy: if you don't see a successful build under heroku webiste's activity tab, but get "everything is up-to-date" when you run
git push heroku <localbranch>:master, or your build doesn't look up-to-date, you can do an empty commit:
git commit --allow-empty -m "force deploy"