Closed olynch closed 1 year ago
Patch coverage: 61.84
% and project coverage change: -1.28
:warning:
Comparison is base (
f86b79f
) 80.89% compared to head (620658a
) 79.62%.:exclamation: Current head 620658a differs from pull request most recent head c4a3043. Consider uploading reports for the commit c4a3043 to get more accurate results
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Since CICD for MTK is going to add a lot of heft to the package, should we factor out these examples into SymbolicLenses.jl or something? Then we can test MTK integration in a separate repo. It looks like we can us GHA to test downstream deps so that Gatlab tests will reflect the status of another package. We could move faster on Gatlab and just make sure that tagged releases of Gatlab don't break the SymbolicLenses.jl package. https://github.com/SciML/SciMLBase.jl/blob/master/.github/workflows/Downstream.yml
Agreed that MTK should not be a hard dependency of this package. I assume that this was just temporary since Gatlab is not yet a released package. On that note, Julia 1.9 will be out soon with better support for optional dependencies, removing the need for Requires.jl.
Since CICD for MTK is going to add a lot of heft to the package, should we factor out these examples into SymbolicLenses.jl or something? Then we can test MTK integration in a separate repo. It looks like we can us GHA to test downstream deps so that Gatlab tests will reflect the status of another package. We could move faster on Gatlab and just make sure that tagged releases of Gatlab don't break the SymbolicLenses.jl package. https://github.com/SciML/SciMLBase.jl/blob/master/.github/workflows/Downstream.yml
I have an issue for this: #47. This is definitely not going to be merged into Gatlab, but I didn't want to go to the bother of creating a new package when I was focused on the demo.
This provides an overload for
ODESystem
that constructs an ODESystem from a lens. This really should be refactored on top of aSystem
struct from #52.