Skip to content

Migrating from Deprecated Workspace Types

In October 2019, several workspace types were deprecated, and you will no longer be able to publish exercises, projects, or Code Challenges using these workspace types:

  • Codex Ruby
  • Codex Python
  • Static
  • Default

TL;DR Migration

Old Workspace New Workspace New Test Type
Codex Ruby Ruby RSpec Test or Component Test
Codex Python Python (2) Python Test or Component Test
Static Static-Web or Language-specific Depedent on workspace type
Default Static-Web or Language-specific Depedent on workspace type

If choosing a language-specific workspace type, refer to Workspace:File Extension Mappings to run the correct file extension.

Codex Ruby

Context

Codex-Ruby is the workspace type in one of Codecademy's oldest extant courses, Learn Ruby. It should not be used for new Ruby content, and the Ruby workspace type provides all necessary functionality to execute Ruby code with the following caveat: interactive input using the gets function will not run or be tested properly in Ruby workspaces using the Run button. Either change to using an interactive terminal and having learners execute their code from the terminal, or ask the LX team to force publish your changes.

Migrating Codex-Ruby

After changing the workspace to Ruby, you must also update tests to run Rspec Test instead of Codex SCT. You can rewrite from scratch using the RSpec documentation, or you can try to migrate:

Workspace updates

Add a spec folder at the root level of the workspace.

Add a Gemfile at the root level with the following contents: gem 'rspec', '3.1'.

How CodexSCT Ruby tests work

CodexSCT tests first execute learner code and then run test code with global variables from the learner's code in the test context. If an error occurred during execution of the learner's code, a global exception object is also present in the test context.

Test pass/fail state is determined by a return statement. true returns will pass the test, where any string is interpreted as an error message to surface to learners:

# Check for any execution errors:
if exception:
  return "Looks like you had the following error: " + exception.to_str
end

# Test a learner variable's existence:
try:
  variable_name
rescue NameError:
  return "Looks like you did not define `variable_name`."
end

if variable_name != 3:
  return "Make sure that `variable_name` equals 3"
end

# Pass the test if all else checks out:
return true

Translating to RSpec Tests

RSpec test differences from CodexSCT:

  • RSpec tests require the rspec describe/it block structure.
  • No learner globals are automatically inserted into an RSpec test's scope. Instead, binding and eval() must be used to load local variables from learner code (see below).
  • Instead of returns, rspec expect() assertions are used to test code. If the test file runs with no exceptions raised from an expect(), the code passes.

To replicate the above CodexSCT test with Rspec Test:

describe 'filepath' do
  it 'test case...' do
    $b = binding

    begin
      eval(File.read('<filepath>'), $b)
    rescue SyntaxError
        expect(1).to eq(0), "It looks like there's a syntax error in your code."
    end

    begin
      $b.eval('variable_name')
    rescue NameError
      # Manually raise an exception
      expect(1).to eq(0) "Looks like you did not define `variable_name`"
    end

    value = $b.eval('variable_name')
    expect(value).to eq(3) "Make sure that `variable_name` equals 3"
  end
end

Codex Python

Context

Codex-Python is the workspace type in one of Codecademy's oldest extant courses, Learn Python, and it executes Python 2 code. It should not be used for new Python content, and the Python workspace type provides all necessary functionality to execute Python code with the following caveat: interactive input using the raw_input() function will not run or be tested properly in Python workspaces using the Run button. Either change to using an interactive terminal and having learners execute their code from the terminal, or ask the LX team to force publish your changes.

Migrating Codex-Python

After changing the workspace to Python (not Python 3), you must also update tests to run Python Test instead of Codex SCT. You can rewrite from scratch using the Python Testing API, or you can try to migrate:

How CodexSCT Python tests work

CodexSCT tests first execute learner code and then run test code with global variables from the learner's code in the test context. If an error occurred during execution of the learner's code, a global error object is also present in the test context.

Test pass/fail state is determined by a return statement. True returns will pass the test, where any string is interpreted as an error message to surface to learners:

# Check for any execution errors:
if error:
  return "Looks like you had the following error: " + str(error)

# Test a learner variable's existence:
try:
  variable_name
except NameError:
  return "Looks like you did not define `variable_name`."

if variable_name != 3:
  return "Make sure that `variable_name` equals 3"

# Pass the test if all else checks out:
return True

Translating to Python Test

Python test differences from CodexSCT:

  • Instead of returns, call the fail_tests(<message>) or pass_tests() function to determine test result
  • Code globals must be explicitly imported into context with load_file_in_context(). This will automatically fail tests if any Exceptions are raised during execution. If you do not want to automatically fail these tests and handle the error in the test file, use the following code blocks in a try/except:
user_code = open('<filepath>', 'r').read()
exec(user_code, globals())

To replicate the above CodexSCT test with Python Test:

load_file_in_context("<filepath>")

full_equality('variable_name', 3, 'explicit')

pass_tests()

Static

Context

Static workspace provides a static webserver to server learner files to the Web Browser component. As a side effect of past code execution architecture, it could also be used as code runner and execute code to a terminal based on the file extension.

Migrating Static

If the workspace requires learner code to be run in the back-end (such as executing a Java or Python file), use those language-specific workspace types. If the workspace is used to serve HTML/CSS/front-end JS files with a web browser cmponent, use the Static-Web workspace type.

Default

Context

Default workspaces allow for basically all code execution and configurations except allowing learners to run a Rails or Node server. It should be avoided in favor of explicit workspace configurations for a certain language or use case.

Migrating Default

If the workspace requires learner code to be run in the back-end (such as executing a Java or Python file), use those language-specific workspace types. If the workspace is used to serve HTML/CSS/front-end JS files with a web browser component, use the Static-Web workspace type.