@GrahamcOfBorg build python3Packages.json5 python3Packages.jsonschema python3Packages.jupyter_core python3Packages.jupyter_client python3Packages.jupyterlab python3Packages.jupyterlab_server

doing the nix-review of this right now..... maybe hold off due to jsonschema>3.... causing a lot of packages to be.... not happy

@GrahamcOfBorg build python3Packages.jupyter_core python3Packages.jupyter_client python3Packages.jupytext

I had to remove the jupyterlab* packages because they depended on jsonschema>=3, which is largely incompatible with the rest of python packages.

@GrahamcOfBorg build python3Packages.jupyter_core python3Packages.jupyter_client python3Packages.jupytext python2Packages.jupyter_core python2Packages.jupyter_client python2Packages.jupytext

@jonringer You could add a separate jsonschema_3 attribute.

@veprbl that may work for non-python packages, however, python packages all share the same PYTHONPATH, so importing a jupyter package, and something which requires jsonschema~=2.0 will break one of those packages, as you don't know which you'll get if you do a import jsonschema :(. This partially works for python2 vs python3, because you're guaranteed to not mix versions of the same package.

Shared global mutable state is the worse 😢

If i was making an application on the other-hand, i could do that. As I could wrap my application with a specific PYTHONPATH. Since i have to worry about downstream packages, i can't in this case :(

see #65023 (comment) for more context

@jonringer
I think you are thinking of a scenario that is a bit pessimistic. Indeed, a naive addition of jsonschema_3 to jupyterlab dependencies might break its combination with some other packages, but that is only few. I have not reviewed all the list of those, but I already can tell that nobody probably wants to use snakemake or poetry in the same environment where they run jupyterlab from. If the issue becomes more pressing we can probably opt to patch the relevant import to use the direct path to jsonschema_3 instead of leaking it to the shared environment.

@veprbl as soon as we let this in we open the door for more such cases. No, we are not going to do this.

@FRidh i removed the need for having a different version of a package, this PR should be good to merge