(feat) Add external:: prefix support for strategy name to load external strategies

[dataroche]

Before submitting this PR, please make sure:

• Your code builds clean without any errors or warnings
• You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:

A bit of context. I have been using Hummingbot for the past 2 years. I developed custom strategies located in the hummingbot/strategy folder. I recently rebased my changes on top of development to use new features, such as the dashboard, and also to be able to contribute back to the upstream project (this one).

Now the issue is that for contributing back to the project, I can't have my private functions in my fork of Hummingbot, since I want to keep it private. So what I'm proposing here is a way to restructure strategies from:

hummingbot/
  hummingbot/
    strategy/
      my_private_strategy/
        start.py
        ...

into

hummingbot/
  ...
my_private_strategy/
  start.py
  ...

In essence, this allows decoupling and removing my strategy files from the main hummingbot repo; allowing me to store it in another, private git repository.

I have arbitrarily chosen external:: as the prefix to the strategy name. I decided to keep this relatively simple and work around the condition that the strategy name must be a string. The PR only modifies the paths and imports required to load a strategy. When the external:: prefix is used, what follows is actually a relative path to the folder containing the strategy files (config map, start.py, etc). For example, I can have a strategy config file such as

strategy: external::../my_private_strategy

To point to my strategy folder as in the example above.

I am open to suggestions, or even alternative ways to achieve the same result. Note that I don't want to use the "scripts" construct to run my strategy, it is written using the old way!

Tests performed by the developer:

• I can run my external strategy
• I can run a built-in strategy (PMM was tested)
• All tests pass (the avellanada tests failed though - number of init_params arguments do not match. I don't think it's related)

Tips for QA testing:

[dataroche]

I have actually been using an alternate method for the last couple of days. I create a symlink folder in the hummingbot/strategy folder, and everything works. It hides my code, if I ever accidently push the symlink nothing is shown.

I.e. ln -s ../../../my_private_strategy my_private_strategy is essentially equivalent to this PR, and then your config file can refer to "my_private_strategy" and everything works. Difference is that your git working directory is now constantly polluted with unstaged changes.

[fengtality]

Hey @dataroche I'm doing some research into how to move the community scripts and strategies into a separate repo and let users import it via git submodule or something like that, so I'll consider this approach as part of it. Let me know if you have any updates.

[dataroche]

Hey @dataroche I'm doing some research into how to move the community scripts and strategies into a separate repo and let users import it via git submodule or something like that, so I'll consider this approach as part of it. Let me know if you have any updates.

Hey @fengtality,

No updates here - my last comment still stands. Right now I'm adding a single file to the Hummingbot repo: a symlink in the strategy folders that points outside of the Hummingbot repo itself. E.g. in the previous example; my setup is

hummingbot/
  hummingbot/
    strategy/
      my_private_strategy (symlink to: ../../../my_private_strategy)
my_private_strategy/
  start.py
  ...

I therefore only have one unstaged change to the Hummingbot repo: the my_private_strategy symlink file.