Find the best way to manage the libs in the monorepo
The services: admin, api, worker, depend on the libs: libcache, libqueue and libutils.

Note that libcache and libutils themselves also depend on libutils.

Currently, the dependencies are defined using a relative path to a wheel file (obtained after running `poetry build` in the library directory):

https://github.com/huggingface/datasets-server/blob/58d47ea57423d9d74f49eb6ba6eafbeee029a92d/services/api/pyproject.toml#L9

Before, they were defined as a relative path to the library directory

https://github.com/huggingface/datasets-server/blob/14d2d0cf40db68434afc7f9cb9f22d43f649999c/services/api_service/pyproject.toml#L9

See https://python-poetry.org/docs/dependency-specification/#path-dependencies.

### Antecedents

Some antecedents to take into account:

- https://github.com/huggingface/datasets-server/issues/216#issuecomment-1139880637:

  > I cannot make it work, since the idea is to avoid using poetry to install, and instead build a wheel and install it: but due to 1. the monorepo structure, with libs/ and services/, which means local relative path that start with ../../libs/, 2. ../ not being supported by pip, 3. git subrepositories not supported by poetry (https://github.com/python-poetry/poetry/pull/5172), I don't know well how to manage it.

- https://github.com/huggingface/datasets-server/pull/314

### Issues with the current solution

One of the issues with the current setup is that if we update one detail in the libutils library for example, we then have to update the file in a lot of places, see https://github.com/huggingface/datasets-server/pull/322/files for example.

Another one is that "Go to definition" on a function in VSCode for example sends to the library files in the virtual environment, not to the upstream files (in libs/).

### Alternatives

An alternative would be to:
- publish the libraries to a public repo, like pypi. It would be easier with #320.
- depend on the remote repo, with a [caret requirement](https://python-poetry.org/docs/dependency-specification/#caret-requirements) so that we could update easily.
Find the best way to manage the libs in the monorepo: The services: admin, api, worker, depend on the libs: libcache, libqueue and libutils.

Note that libcache and libutils themselves also depend on libutils.

Currently, the dependencies are defined using a relative path to a wheel file (obtained after running `poetry build` in the library directory):

https://github.com/huggingface/datasets-server/blob/58d47ea57423d9d74f49eb6ba6eafbeee029a92d/services/api/pyproject.toml#L9

Before, they were defined as a relative path to the library directory

https://github.com/huggingface/datasets-server/blob/14d2d0cf40db68434afc7f9cb9f22d43f649999c/services/api_service/pyproject.toml#L9

See https://python-poetry.org/docs/dependency-specification/#path-dependencies.

### Antecedents

Some antecedents to take into account:

- https://github.com/huggingface/datasets-server/issues/216#issuecomment-1139880637:

  > I cannot make it work, since the idea is to avoid using poetry to install, and instead build a wheel and install it: but due to 1. the monorepo structure, with libs/ and services/, which means local relative path that start with ../../libs/, 2. ../ not being supported by pip, 3. git subrepositories not supported by poetry (https://github.com/python-poetry/poetry/pull/5172), I don't know well how to manage it.

- https://github.com/huggingface/datasets-server/pull/314

### Issues with the current solution

One of the issues with the current setup is that if we update one detail in the libutils library for example, we then have to update the file in a lot of places, see https://github.com/huggingface/datasets-server/pull/322/files for example.

Another one is that "Go to definition" on a function in VSCode for example sends to the library files in the virtual environment, not to the upstream files (in libs/).

### Alternatives

An alternative would be to:
- publish the libraries to a public repo, like pypi. It would be easier with #320.
- depend on the remote repo, with a [caret requirement](https://python-poetry.org/docs/dependency-specification/#caret-requirements) so that we could update easily.