The intention of the toolset is to extend use of a local clone of the Lean source code. In fact this project pre-dates the first publish of the QuantConnnect nuget by a few years, which is how it comes to be that way. It's expected users will already have a familiarity with some of the config and logging options of Lean when coming to the optimization tools.
However, some would prefer to pull, build and restore and be ready to run. It's worth considering compelling reasons for/against switching to the official package or a dedicated optimization package.
For one thing I don't know if the official QC Engine nuget references every Lean library that you might like to use in your algorithms or that the Optimization depends on.
For another, I personally choose to make minor tweaks to the Lean source, such as disable some of the logging and timeouts which could not be done with the official nuget.
lefig
commented
3 years ago
The intention of the toolset is to extend use of a local clone of the Lean source code. In fact this project pre-dates the first publish of the QuantConnnect nuget by a few years, which is how it comes to be that way. It's expected users will already have a familiarity with some of the config and logging options of Lean when coming to the optimization tools.
However, some would prefer to pull, build and restore and be ready to run. It's worth considering compelling reasons for/against switching to the official package or a dedicated optimization package.
For one thing I don't know if the official QC Engine nuget references every Lean library that you might like to use in your algorithms or that the Optimization depends on.
For another, I personally choose to make minor tweaks to the Lean source, such as disable some of the logging and timeouts which could not be done with the official nuget.