jupyterlab-requirements should support fallback to micropipenv

[llunved]

Describe the bug
jupyterlab-requirements fallback requires pipenv. It should use micropipenv if that is available instead.

To Reproduce
Steps to reproduce the behavior:

1. Create a container with jupyterlab-requirements and only micropipenv.
2. Create a notebook and add a dependency.
3. Try to resolve locally.
4. See error

[pacospace]

Thanks @llunved for opening this issue!

Micropipenv (https://github.com/thoth-station/micropipenv), despite the name, it is not a resolver, but it is used to install dependencies from a solved stack in containers.
In jupyterlab-requirements it is used once the locked files (created with Thoth or Pipenv) have been created.

So micropipenv cannot be used as fallback. For sure we can improve the message:

We can ask users to install Pipenv if they want to use the other resolution engine.

While for Thoth, we could list the environments available where Thoth has knowledge about.
(ubi 8 py38, fedora 34 py39 currently).

The UI in jupyterlab-requirements uses thoth by default and pipenv if there is any error. But in the magic commands and the cli this is not the case. User has to choose the dependency resolution engine.
Maybe we will standardize the behaviour also for the UI.

[fridex]

it is used to install dependencies from a solved stack

That is true. Moreover, micropipenv fallbacks to pip's resolution algorithm if the provided requirements are not locked which could fit into the requested feature. However, micropipenv (as of now) has no mechanism to obtain the locked stack from pip's resolution (related: thoth-station/micropipenv#151). We are monitoring efforts that want to bring pip's resolver into pip-tools in jazzband/pip-tools#1539. If that will be successful, we can check if pip's resolver API provides required features (such as specifying packages across indexes) -- if yes, we can try to incorporate pip's resolver into micropipenv so that micropipenv produces a lockfile in the end. It might be beneficial for provided environments (to still have a client resolver and not require to maintain pipenv as an rpm).

[goern]

Micropipenv (https://github.com/thoth-station/micropipenv), despite the name, it is not a resolver, but it is used to install dependencies from a solved stack in containers.
In jupyterlab-requirements it is used once the locked files (created with Thoth or Pipenv) have been created.

This is a good explanation, could you add it to the screen show above?

[goern]

what is the status of this one?

[goern]

/kind feature

[pacospace]

what is the status of this one?

I'm gonna add the message to the UI and we can close this.