[Romazes]

Description

Adds eToro to the live deployment and data download commands. The change is the regenerated README.md, because the module itself is described in modules-1.14.json, which this repository does not track; the module entry is sent to the team separately.

The module is a brokerage, a data queue handler, a history provider and a data downloader: the plugin (Lean.Brokerages.Etoro, PR #5) streams instrument rates as ticks and reads quote bars from the eToro candles. It trades equities, crypto and currency pairs with market orders. It asks for three values:

--etoro-api-key TEXT            Your eToro API key
--etoro-user-key TEXT           Your eToro user key
--etoro-environment [real|demo]
                                Whether the real or the demo eToro account should be used; the key pair must be
                                created for that account

The user key is a password prompt. The environment choice sets the etoro-demo-environment flag of the plugin, the way the Alpaca module sets alpaca-paper-trading from its environment choice. The API address is an internal input, so nobody is asked for it. The specifications point at etoro.json in the plugin repository. Product id 465.

Related PR(s)

Lean core: QuantConnect/Lean#9886

Related Issue

N/A

Motivation and Context

Without this, lean live deploy, lean cloud live deploy and lean data download do not offer eToro, so the plugin cannot be used from the CLI.

Requires Documentation Change

The brokerage needs its own page under the live trading brokerages section, like the other brokerages have.

How Has This Been Tested?

• Loaded the module through the CLI loader with the entry in modules-1.14.json. get_configs_for_options("live-cli") and get_configs_for_options("live-cloud") both return the three eToro options: etoro-api-key, etoro-user-key, etoro-environment.
• README.md was regenerated with scripts/readme.py. The change is 39 added lines and 9 replaced lines, all of them eToro: the brokerage and data provider choices of six commands, and the three options under each.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>