search

tensortrade-org / tensortrade

An open source reinforcement learning framework for training, evaluating, and deploying robust trading agents.
https://discord.gg/ZZ7BGWh
Apache License 2.0
4.52k stars 1.02k forks source link

Write a compatibility matrix between TensorTrade, Ray, PyTorch, etc #379

Open carlogrisetti opened 2 years ago

carlogrisetti commented 2 years ago

We need to have some sort of compatibility matrix to guide users in choosing the "best" (read: tested) versions for their environment. Ray was chosen as the best way to go forward mainly to offload all the agent implementation to their group, but it's not always stable and under heavy development.

I am currently using: TensorTrade 1.0.4-dev0 (master) Python 3.7.12 Ray 1.9.2 (latest) PyTorch 1.10.1 (latest)

abstractguy commented 2 years ago

This won't be needed, as everything is now in setup.py, installing more recent versions of those packages and more

carlogrisetti commented 2 years ago

One does not always want to install a more recent version. We dropped Python 3.6 support, but it could be useful to let people know that yes, testing is deployed for python 3.7 3.8 3.9, but there is a real use case where Python 3.7.2 is used (fo example).

This would give people with issues a starting baseline to have the most "field-tested" configuration possible, and exclude a peculiar version issue. This often happens with the most recent release of a component, where a breaking change is introduced but (for example) the base Python requirement is not bumped to a higher version, giving issues with a "generic" 3.7 (which could install a 3.7.13 when it's released), but it works fine on 3.7.12.

Also, tests are not scheduled recurringly, so if the latest commit was tested against 3.7.12 and 3.7.13 gets released, that version is by all means untested.

abstractguy commented 2 years ago

One does not always want to install a more recent version. We dropped Python 3.6 support, but it could be useful to let people know that yes, testing is deployed for python 3.7 3.8 3.9, but there is a real use case where Python 3.7.2 is used (fo example).

This would give people with issues a starting baseline to have the most "field-tested" configuration possible, and exclude a peculiar version issue. This often happens with the most recent release of a component, where a breaking change is introduced but (for example) the base Python requirement is not bumped to a higher version, giving issues with a "generic" 3.7 (which could install a 3.7.13 when it's released), but it works fine on 3.7.12.

Also, tests are not scheduled recurringly, so if the latest commit was tested against 3.7.12 and 3.7.13 gets released, that version is by all means untested.

Ugh... eager for this version management to be over with so I can focus on more interesting stuff without managing multiple install procedures. I still need a few changes made to the install before I make bigger commits.