Update coverage, reporting approaches

[bollwyvl]

References

• fixes Coverage calculation has degraded? #1038

Code changes

TBD

User-facing changes

TBD

Backwards-incompatible changes

TBD

Chores

• linted
• tested
• documented
• changelog entry

[github-actions]

👈 Launch a binder notebook on branch bollwyvl/jupyterlab-lsp/gh-1038-fix-cov

[bollwyvl]

Yep, with the latest setuptools, etc. definitely can't build the wheel. Still looking...

[bollwyvl]

As per discussion at the JupyterLab meeting, going to pivot this PR to getting everything to build against jupyterlab >=4.1.0 and the jupyter_server it requires (>=2.4.0,<3).

[krassowski]

Suggested change

	or `jupyter server extension list` (JupyterLab < 3) from the command line here.
	from the command line here.

[bollwyvl]

Didn't make a ton of progress worth showing on this over the weekend. 😅 While the python unit/integration tests run, I'm still getting ~80 robot acceptance fails. I was able to fix a few of these by replacing standards-based selectors like button with jp-button (ugh), but there must be some more key breaking changes in 4.1 I'm haven't tracked down yet.

I've barely looking into it, but the jest unit tests will need some work, e.g. the adapterTrack was added upstream, and haven't had time to dig into what that means.

In working on it, though, I am feeling more and more that this project needs at least a concrete, documented way to handle local/CI incremental development and testing that does a much better job of managing (multiple) environments. My preference, I guess, would be doit for general top-level automation. I'd really rather not invest more into nx or some nodejs alternative... indeed, we could likely remove lerna and nx entirely, as package.json#/workspaces does 99% of what we need to happen, given another data-driven task runner.

A big win would be accepting micromamba as a base coat (perhaps even going as far as submoduling a vendored binaries 🙀 ) for environments, locks, running, etc. We could then substantially slim down our build environment, and split some of our heavyweight environments that cause icky solveability issues (looking at you, r-base -> icu).

[krassowski]

Thanks!

I can work on jest tests and robot failures. If this is easier to test CI for you, maybe it is worth xfail the jest tests which are failing for now.

I'd really rather not invest more into nx or some nodejs alternative... indeed, we could likely remove lerna and nx entirely, as package.json#/workspaces does 99% of what we need to happen, given another data-driven task runner.

Sure!

My preference, I guess, would be doit for general top-level automation

That's another tool on top of already pretty custom stack. I guess scripts with hatch run could do some of it. But sure, doers decide and I will respect whichever way you go here.

[bollwyvl]

That's another tool on top of already pretty custom stack.

Well, it's kind of a stack... but doesn't know when to push or pop, or even what's in it, or where the stack is. Instead of having to look at (and fully document) all the intent in scripts, I propose the file-based relationships of what goes into and out of the scripts (and the things that aren't there, like all the custom CI env stuff) would be in a single, maximally-declarative configuration script.

hatch run

A PEP517 build backend (e.g. hatchling, flit-core, poetry-core) is a separate choice, altogether, and picking their "heavyweight" counterparts make it much harder to change that opinion in the future. hatch-conda makes me shiver, but not as much as the poetry infinite universe of sadness.

I still think "has some non EOL python" is a reasonable thing to expect at the bottom of a new stack, but pretty much everything after should run in an isolated environment.

doers

Right: prior, public art at an even larger scale (jupyak, jupyterlite) shows this does work to make the system more robust and understandable, so the doing won't even be that bad.

[krassowski]

And now it took 30 minutes to prettier all .mypy_cache files..