Turns off:
- no-explicit-any (we need to handle any return values from runPython)
- no-unsafe-assignment (noisy and pointless)
And resolves all but two remaining ones. The last two lints regard access to private Pyodide variables and so:
- they are not easy to work around without an upstream Pyodide patch
- they should trigger linter and require explicit override
* Unvendor toml package
* Fix many ESlint errors
For mysterious reasons, these errors appear on my branch #1262 even
though they are not related to changes there. The eslint config seems
a bit unstable.
Anyways this fixes them.
* Put back Record
* Fix typescript compilation
* Fix lints
* Try @iarna/toml instead
* Fix import
* Use @ltd/j-toml
* Update test
* Use toml-j0.4
* Some changes
* Fix toml import
* Try adding eslint gha job
* Add forgotten checkout action
* Force CI to run
* Blah
* Fix
* Revert changes to github workflow
* Fix lints
* wget toml-j0.4 type definitions
* Add toml-j types workaround to eslint workflow
* Apply formatter
* Use @hoodmane/toml-j0.4
* Import from @hoodmane/toml-j0.4
* split interpreter class
* add new files
* add newlines
* disable eslint for run
* remove usage of interpreter from unit test
* delete fakeinterpreter class
* fix unit tests
* add comments
* remove interpreter.ts and pyodide.ts files
* suggested changes
* Add display impl, remove outputManage, print and console.log defaults to terminal
* Fixing tests
* Lint
* Erase unecessary code, add cuter CSS formating for errors, fix problems around REPL output
* Add fix to repl2 and lint
* lint
* Allow for list of display, fix elif to else
* Add better global option
* test work
* xfails
* (antocuni, mariana): let's try to start again with TDD methodology: write the minimum test and code for a simple display()
* (antocuni, mariana): this test works out of the box
* WIP: this test is broken, mariana is going to fix it
* add a failing test
* Add ability to deal with targets
* Add append arg and append tests
* Add multiple values to display
* Small adjustments to tests. I noticed I wasn;t running all at some point
* add display test
* Add console tests
* Add async tests
* Fix repl tests
* Fixing merging issues
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Address antocuni's review
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Fixing more tests
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* linting
* Improve repl tests
* Change my test so codespell is hapy with it
* Test: change test_runtime_config to use json instead of toml to see if stops failing on CI
* kill this file: it is a merge artifact since it was renamed into test_py_config.py on the main branch
* Change test execution order and add async tests to async test file
Co-authored-by: Antonio Cuni <anto.cuni@gmail.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
As the title stays, the main goal of the branch is to kill the infamous runtimeLoaded global store and all the complications, problems and bugs caused by the fact that in many places we needed to ensure/wait that the global runtime was properly set before being able to execute code.
The core idea is that runtime is never a global object and that it's passed around explicitly, which means that when a function receives it, it is guaranteed to be initialized&ready.
This caused a bit of complications in pybutton.ts, pyinputbox.ts and pyrepl.ts, because they indirectly want to call runtime.run from connectedCallback, which is the only place where we cannot explicitly pass the runtime because it's automatically called by the browser.
But also, it is also a sign of a bad design, because it were entirely possible that connectedCallback was called before the runtime was ready, which probably caused many bugs, see e.g. #673 and #747.
The solution to is use dependency injection and create the class later on: so instead of having a global PyButton class which relies on a global runtime (whose state is uncertain) we have a make_PyButton function which takes a runtime and make a PyButton class which is tied to that specific runtime (whose state is certainly ready, because we call make_PyButton only when we know that the runtime is ready).
Similar for PyInputBox and PyRepl.
Other highlights: thanks to this, I could kill the also infamous runAfterRuntimeInitialized and a couple of smelly lines which used setTimeout to "wait" for the runtime.
While I was at it, I also called a lot of other stores which were completely unused and where probably leftovers from a past universe.
