Add backend version configuration

This release makes the Alpaca API version configurable. It also makes some preparations for anticipated shorting features - namely, automatic handling long-to-short (or short-to-long) position changes in Quantopian compatibility mode.

Fix open order initialization and add redis storage

This update fixes two issues with order initialization: one where the list was not being retrieved from the API, and another where a race condition might occur between initialization and the stream opening. It also adds support for a redis backend which people might find necessary in an environment like Heroku. Please see the updated readme section on running with redis for more info. Redis support was added by @trobrock .

Realtime Open Order Status

This release is a first step towards addressing some of the issues people have encountered due to delayed updates. In order to avoid spamming the API and performing heavy calculations too frequently, there is some information that pylivetrader only retrieves from the API once a minute. This has caused people to encounter some issues when tracking their order statuses and positions. This update makes it so that the open order list for the Alpaca backend is updated in real time with websocket streaming. In the future, we want to continue to use streaming data to support use cases which rely on realtime data updates in pylivetrader.

Fix pickle loading error and reject API method overwriting

• There was an issue where a file with a size of 0 could cause errors when loading the pickle file, which has been resolved.
• Because the context object shares a namespace with the API, setting something like context.symbol='AAPL' would overwrite the symbol() API method. This created a problem that was particularly difficult to debug because the overwrite was persisted in the pickle file. For now, we're rejecting attempts to set anything on the context object that would share a name with an API method. We may attempt to separate the namespaces at a later time to avoid people running into this error when bringing in Quantopian scripts.

Quantopian Compatibility Mode

Starting with v0.0.21, Pylivetrader now runs by default in what will be referred to as Quantopian compatibility mode. Notable changes that were made in response to issue #72 :

• Using the current() function to get 'price' data previously behaved the same way as using current() to get 'last_traded'. Rather than retrieving the last trade update, in Quantopian compatibility mode, using current() to get 'price' will instead return the 'close' value of the most recently finished bar. This is to reduce confusion for users bringing in scripts from Quantopian, where that is the expected behavior.

• It is now much less likely that price data coming from the history() function will be NaN, even when selecting small bar sizes. If any true value is found, it will be forward and backward filled to cover NaN entries. However, if a small number of bars was requested, it was possible that all values seen would be NaN, and therefore there would be nothing to cover them with. In Quantopian compatibility mode, if all values seen are NaN, the query for data will now be repeated (up to three times,) looking farther back each time for non-NaN data.

Quantopian compatibility mode can be disabled to achieve the previous behavior if you specify -q 0 as an argument when running pylivetrader from the command line.

Logging configuration and portfolio query improvements

The default logger level has been changed to "INFO," and can now be set to a different level with a command line argument. We also fixed an issue that could occur when querying the portfolio if Polygon returned nothing for last_trade information on a symbol - now, these cases will be identifiable by a NaN price and NaT timestamp.

get_all_orders hotfix

Fixing an issue with the timestamp being passed to the trading_calendars library.

Order querying improvements

get_all_orders() is now configurable with its days_back parameter - it will now return only as many (market) days as are requested. The default behavior is to get all orders, so be sure to limit your calls if possible to get a performance boost. get_recent_orders exists as a convenience method to get orders of all types from the last few days, and defaults to 2 days of data.

An issue was also fixed where get_order would not return older orders. get_order should now return the order regardless of how long ago it was submitted.

Add get_all_orders and extend output for get_open_orders

Enables easier handling of cases where more orders than the maximum number the server will return are present.

Improve order logging

Added some additional info in order logging