- better type inference with JSON output: integers are now returned as integers instead of as floats
- exchange rates from a base currency to itself are now stored as a convenience
- layer sharing upgrade
Changes since the initial release of QuantRocket are documented here.
Due to QuantRocket's microservice architecture, each service/container has its own version number and history, rather than the entire application having a single version number and history. Each service's version numbers increment freely; that is, version 1.1.1 of service A doesn't necessarily correspond to or require version 1.1.1 of service B. In some cases new features in a particular service do require a particular minimum version of another service; these dependencies are noted in the release notes.
There are two options for how to upgrade your versions: a full upgrade or a partial upgrade.
At any time, the Configuration Wizard can be used to generate a YAML file containing the latest versions of each image. You can upgrade your entire deployment by generating a new YAML file to replace your existing YAML file. This ensures that all service dependencies are satisfied and that the behavior of your deployment matches the website documentation.
Alternatively you can use the release notes to pick and choose particular version upgrades. Modify your existing YAML file to reference the new version of the image. For example, to upgrade to version 184.108.40.206 of the Juptyer service, modify the relevant section of your YAML to read:
jupyter: image: 'quantrocket/jupyter:220.127.116.11'
Whether you choose a full or partial upgrade, you can deploy the changes as normal using Docker Compose or Docker Cloud. For local deployments:
docker-compose -p quantrocket up -d
For cloud deployments, log in to Docker Cloud, save the new Stack file, then go to: Stacks > Actions > Redeploy.
From some release notes below you will see the words "layer sharing upgrade."
QuantRocket Docker images inherit from a common base image which supplies a variety of libraries needed by all images. A benefit of using a common base image is that the layers of the base image are shared by all child images which results in faster pulls when downloading images and less disk spaced used on your computer.
To maximize layer sharing, whenever a change is made to the base image, new versions of all child images are also released, even if the child images include no new features.
improve handling of IB response timeouts
Previously when the IB API failed to respond to a request after 30 seconds, the history service would log the failure and continue with the next request for the same security. Since non-responses from the IB API are usually temporary, and since the history service fills data from back to forwards (old to new), this behavior could lead to gaps in the data. Now, after a non-response from the IB API, the history service will skip to the next security to avoid creating data gaps.
make runtime estimates more informative by including average response time and number of remaining requests
automatically packagify codeload directory and subdirectories and make them importable using
Any folders under the
codeload directory which are valid Python package names (lowercase letters and underscores) and which contain one or more
.py files will automatically be packagified, that is, an
__init__.py file will be created if it doesn't already exist. Packages can be imported from the top-level
codeload package using standard Python dot notation. For example, a function called
my_function located in
codeload/moonshot/utils.py can be imported in Jupyter notebooks as follows:
from codeload.moonshot.utils import my_function