Fix for getting core_path

[fcollonval]

@cronan03 to solve the issue for

https://github.com/jupyterlab/jupyterlab-builder/blob/727dc285ea97b730068731c177915144b61a8fd7/jupyter_builder/federated_extensions.py#L202

I suggest you replace osp.join(HERE, "staging") by a call to a new function default_core_path that will have the following implementation:

from pathlib import Path

def default_core_path() -> str:
    import jupyterlab
    return str(Path(jupyterlab.__file__).parent / "staging")

[cronan03]

Hey, this was the error I was facing.

[bollwyvl]

Making the python-side jupyterlab import lazy, but then using default_core_path in most places that actually do something inside a pyproject-build environment means there is no effective reduction in circular dependencies, and the error messages would be ModuleNotFound or ImportError deep inside labextension build inside hatchling (or whatever) instead of a solver error on most python environments.

Briefly discussed on some past Wednesday: looking deeper into why core_path is needed, it looks like it's generally for the package.json for a specific installable release... indeed sometimes to find out metadata about builder itself.

An approach to providing this: retroactively (and in an automated fashion) publish a new npm package, e.g. jupyterlab-application-top-4.0.0.tgz for each release, containing only the required metadata and support files, indeed maybe moving dependencies to someplace else in the file such that it didn't bring in the entire application, which would be hurtful in its own way.

The builder itself (but never a jupyter application) could then depend on one of these versions, concretely documenting the minimum supported release the builder will support (e.g. 4.0.0), and could be overloaded by an extension by declaring it next to builder in its devDependencies rather than some newly minted package.json#jupyter convention.