Release 1.145.0

See release notes.

Author: cjdsellers

.gitignore

@@ -46,5 +46,5 @@ output.json
 examples/backtest/notebooks/catalog
 nautilus_trader/**/.gitignore
 docs/**/*.ipynb
-!nautilus_trader/core/pytime.h
 !nautilus_core/lib/**/*
+!nautilus_trader/core/includes/**

RELEASES.md

@@ -1,3 +1,23 @@
+# NautilusTrader 1.145.0 Beta
+
+Released on 15th May 2022 (UTC).
+
+This is an early release due to the build error in the sdist for `1.144.0`.
+The error is due to the `nautilus_core` Rust source not being included in the sdist package.
+
+### Breaking Changes
+- All raw order constructors now take `expire_time_ns` int64 rather than a datetime
+- All order serializations due to `expire_time_ns` option handling
+- `PortfolioAnalyzer` moved from `Trader` to `Portfolio`
+
+### Enhancements
+- `PortfolioAnalyzer` now available to strategies via `self.portfolio.analyzer`
+
+### Fixes
+None
+
+---
+
 # NautilusTrader 1.144.0 Beta
 
 Released on 10th May 2022 (UTC).

docs/user_guide/advanced/portfolio_statistics.md

@@ -44,7 +44,7 @@ These statistics can then be registered with a traders `PortfolioAnalyzer`.
 ```python
 stat = WinRate()
 
-engine.trader.analyzer.register_statistic(stat)
+engine.portfolio.analyzer.register_statistic(stat)
 ```
 
 ```{tip}

docs/user_guide/backtest_example.md

@@ -1,6 +1,6 @@
 # Complete Backtest Example
 
-This notebook runs through a complete backtest example using raw data (external to nautilus) to a parameterised run 
+This notebook runs through a complete backtest example using raw data (external to Nautilus) to a single backtest run.
 
 <!-- #region tags=[] -->
 
@@ -29,7 +29,7 @@ from nautilus_trader.persistence.external.readers import TextReader
 
 ## Getting some raw data
 
-Before we start the notebook - as a once off we need to download some sample data for backtesting
+Before we start the notebook - as a once off we need to download some sample data for backtesting.
 
 For this notebook we will use FX data from `histdata.com`, simply go to https://www.histdata.com/download-free-forex-historical-data/?/ascii/tick-data-quotes/ and select an FX pair, and one or more months of data to download.
 
@@ -40,7 +40,7 @@ Once you have downloaded the data, set the variable `DATA_DIR` below to the dire
 DATA_DIR = "~/Downloads/"
 ```
 
-Run the cell below; you should see the files that you downloaded
+Run the cell below; you should see the files that you downloaded:
 
 ```python
 fs = fsspec.filesystem('file')

docs/user_guide/core_concepts.md

@@ -6,27 +6,42 @@ performance with a high quality user experience, within the bounds of a robust P
 - Backtesting trading strategies
 - Deploying trading strategies live
 
+The projects codebase provides a framework for implementing systems to achieve the above. You will find
+the default `backtest` and `live` system implementations in their respectively named subpackages. All examples
+will also either utilize the default backtest or live system implementations.
+
 ## System Architecture
+
+### Common core
+NautilusTrader has been designed to share as much common code between backtest and live systems as possible. This
+is formalized in the `system` subpackage, where you will find the `NautilusKernel` class, providing a common core system kernel.
+
+A _ports and adapters_ architectural style allows modular components to be 'plugged into' the
+core system, providing many hook points for user defined / custom implementations.
+
+### Messaging
+To facilitate this modularity and loose coupling, an extremely efficient `MessageBus` passes data, commands and events as messages between components.
+
 From a high level architectural view, it's important to understand that the platform has been designed to run efficiently 
 on a single thread, for both backtesting and live trading. A lot of research and testing
 resulted in arriving at this design, as it was found the overhead of context switching between threads
 didn't pay off in better performance.
 
-For live trading, extremely high performance (benchmarks pending) can be achieved running asynchronously on a single [event loop](https://docs.python.org/3/library/asyncio-eventloop.html), 
-especially leveraging the [uvloop](https://github.com/MagicStack/uvloop) implementation (available for Linux and macOS only).
+When considering the logic of how your trading will work within the system boundary, you can expect each component to consume messages
+in a predictable synchronous way (_similar_ to the [actor model](https://en.wikipedia.org/wiki/Actor_model)).
 
 ```{note}
-Of interest is the LMAX exchange architectire, which achieves award winning performance running on
+Of interest is the LMAX exchange architecture, which achieves award winning performance running on
 a single thread. You can read about their _disruptor_ pattern based architecture in [this interesting article](https://martinfowler.com/articles/lmax.html) by Martin Fowler.
 ```
 
-When considering the logic of how your trading will work within the system boundary, you can expect each component to consume messages
-in a predictable synchronous way (_similar_ to the [actor model](https://en.wikipedia.org/wiki/Actor_model)).
-
 ## Trading Live
 A `TradingNode` can host a fleet of trading strategies, with data able to be ingested from multiple data clients, and order execution handled through multiple execution clients.
 Live deployments can use both demo/paper trading accounts, or real accounts.
 
+For live trading, extremely high performance (benchmarks pending) can be achieved running asynchronously on a single [event loop](https://docs.python.org/3/library/asyncio-eventloop.html), 
+especially leveraging the [uvloop](https://github.com/MagicStack/uvloop) implementation (available for Linux and macOS only).
+
 ## Data Types
 The following market data types can be requested historically, and also subscribed to as live streams when available from a data publisher, and implemented in an integrations adapter.
 - `OrderBookDelta`
@@ -44,10 +59,13 @@ The following PriceType options can be used for bar aggregations;
 - `LAST`
 
 The following BarAggregation options are possible;
+- `MILLISECOND`
 - `SECOND`
 - `MINUTE`
 - `HOUR`
 - `DAY`
+- `WEEK`
+- `MONTH`
 - `TICK`
 - `VOLUME`
 - `VALUE` (a.k.a Dollar bars)
@@ -58,16 +76,16 @@ The following BarAggregation options are possible;
 - `VALUE_IMBALANCE`
 - `VALUE_RUNS`
 
-The price types and bar aggregations can be combined with step sizes >= 1 in any way through `BarSpecification`. 
-This enables maximum flexibility and now allows alternative bars to be produced for live trading.
+The price types and bar aggregations can be combined with step sizes >= 1 in any way through a `BarSpecification`. 
+This enables maximum flexibility and now allows alternative bars to be aggregated for live trading.
 
 ## Account Types
 The following account types are available for both live and backtest environments;
 
-- `Cash` single-currency (base currency).
-- `Cash` multi-currency.
-- `Margin` single-currency (base currency).
-- `Margin` multi-currency.
+- `Cash` single-currency (base currency)
+- `Cash` multi-currency
+- `Margin` single-currency (base currency)
+- `Margin` multi-currency
 
 ## Order Types
 The following order types are available (when possible on an exchange);

docs/user_guide/strategies.md

@@ -5,8 +5,8 @@ trading strategies. Defining a trading strategy is achieved by inheriting the `S
 and implementing the methods required by the strategy.
 
 Using the basic building blocks of data ingest and order management (which we will discuss
-below), it's possible to implement any type of trading strategy including positional, momentum, re-balancing,
-pairs trading, market making etc.
+below), it's possible to implement any type of trading strategy including directional, momentum, re-balancing,
+pairs, market making etc.
 
 Please refer to the [API Reference](../api_reference/trading.md#strategy) for a complete description
 of all the possible functionality.
@@ -19,6 +19,16 @@ There are two main parts of a Nautilus trading strategy:
 Once a strategy is defined, the same source can be used for backtesting and live trading.
 ```
 
+## Implementation
+Since a trading strategy is a class which inherits from `Strategy`, you must define
+a constructor where you can handle initialization. Minimally the base/super class needs to be initialized:
+
+```python
+class MyStrategy(Strategy):
+    def __init__(self):
+        super().__init__()  # <-- the super class must be called to initialize the strategy
+```
+
 ## Configuration
 The main purpose of a separate configuration class is to provide total flexibility
 over where and how a trading strategy can be instantiated. This includes being able
@@ -37,7 +47,7 @@ from decimal import Decimal
 from nautilus_trader.config import StrategyConfig
 
 
-class MyStrategy(StrategyConfig):
+class MyStrategyConfig(StrategyConfig):
     instrument_id: str
     bar_type: str
     fast_ema_period: int = 10
@@ -53,6 +63,24 @@ config = MyStrategy(
 )
 ```
 
+Once a configuration is defined and instantiated, we can pass this to our trading strategy. Here we simply add an instrument ID
+as a string, to parameterize the instrument the strategy will trade.
+
+```python
+class MyStrategy(Strategy):
+    def __init__(self, config: MyStrategyConfig):
+        super().__init__(config)
+
+        # Configuration
+        self.instrument_id = InstrumentId.from_str(config.instrument_id)
+```
+
+```{note}
+Even though it often makes sense to define a strategy which will trade a single
+instrument. There is actually no limit to the number of instruments a single strategy
+can work with.
+```
+
 ### Multiple strategies
 If you intend running multiple instances of the same strategy, with different
 configurations (such as trading different instruments), then you will need to define
@@ -71,34 +99,3 @@ example the above config would result in a strategy ID of `MyStrategy-001`.
 ```{tip}
 See the `StrategyId` [documentation](../api_reference/model/identifiers.md) for further details.
 ```
-
-## Implementation
-Since a trading strategy is a class which inherits from `Strategy`, you must define
-a constructor where you can handle initialization. Minimally the base/super class needs to be initialized:
-
-```python
-class MyStrategy(Strategy):
-    def __init__(self):
-        super().__init__()  # <-- the super class must be called to initialize the strategy
-```
-
-As per the above, it's also possible to define a configuration. Here we simply add an instrument ID
-as a string, to parameterize the instrument the strategy will trade.
-
-```python
-class MyStrategyConfig(StrategyConfig):
-    instrument_id: str
-
-class MyStrategy(Strategy):
-    def __init__(self, config: MyStrategyConfig):
-        super().__init__(config)
-
-        # Configuration
-        self.instrument_id = InstrumentId.from_str(config.instrument_id)
-```
-
-```{note}
-Even though it often makes sense to define a strategy which will trade a single
-instrument. There is actually no limit to the number of instruments a single strategy
-can work with.
-```

examples/notebooks/backtest_example.ipynb

@@ -82,7 +82,7 @@
     "            bar_type=\"EUR/USD.SIM-15-MINUTE-BID-INTERNAL\",\n",
     "            fast_ema=10,\n",
     "            slow_ema=20,\n",
-    "            trade_size=Decimal(1_000_000),\n",
+    "            trade_size=Decimal(100_000),\n",
     "        ),\n",
     "    ),\n",
     "]\n",

nautilus_core/.cargo/config.toml

@@ -1,5 +1,13 @@
 [target.x86_64-pc-windows-msvc]
-rustflags = ["-C", "target-feature=+crt-static"]
+rustflags = [
+    "-C", "target-feature=+crt-static",
+]
+
+[target.x86_64-apple-darwin]
+rustflags = [
+    "-C", "link-arg=-undefined",
+    "-C", "link-arg=dynamic_lookup",
+]
 
 [target.x86_64-unknown-linux-musl]
 linker = "rust-lld"