jupyter_core icon indicating copy to clipboard operation
jupyter_core copied to clipboard

"There is no reason to install this package on its own" does not play well with pipx / uv

Open callegar opened this issue 5 months ago • 1 comments

In many cases, python tools are now installed using pakage/project managers such as pipx or uv, that also know how to deal with them. For instance, uv has its tool subcommand for that.

Now, to install jupyterlab in this way, you need to ask uv to install jupyter-core, not jupyter lab, because it is jupyter-core that provides the jupyter entry point to be exposed by uv.

So you need to do: uv tool install jupyter-core --with jupyterlab.

Now, yes, there is a jupyter metapackage, but it provides no binaries if installed with uv tool!

The instruction on pypi that "There is no reason to install this package on its own" is thus a bit misleading wrt to the usage of jupyter together with uv/pipx.

As a matter of fact, it would be great to say uv tool install jupyter-core[jupyterlab] having the package exposing jupyterlab (and maybe more) as extras.

callegar avatar Jun 19 '25 07:06 callegar

Interesting! pipx is indeed an installation pattern we didn't have in mind years ago, so it was a safe assumption that dependencies are fully installed (including cli dependencies, which describes the jupyter lab dependency), and I guess dependencies on $PATH aren't really considered in those tools, since they break such installations.

We'll need to think about the best way to work in this context, it's not obvious to me.

In the meantime, launching entry points directly (jupyter-lab instead of subcommand invocation jupyter lab) works, e.g.

pipx run --spec jupyterlab jupyter-lab
# or
uvx --from jupyterlab jupyter-lab

So maybe the right answer is to point to jupyter-lab more often, because it is not the case that you need to explicitly install jupyter-core via uv/pipx, but you do need to invoke the entry points directly since the subcommand invocation won't work in these situations.

minrk avatar Jun 19 '25 13:06 minrk

Do any of these tools have a spec for identifying the "canonical" entry point via metadata, rather than the extremely inflexible executable==pkg name guess? Lots of packages don't follow that pattern, so it seems like there should be a way.

minrk avatar Jun 28 '25 21:06 minrk