Skip to content

ModuleNotFoundError: No module named 'geopandas' in Docker environment #2180

@Rikuoja

Description

@Rikuoja

Description
Despite Geopandas being included in requirements-provider.txt, trying to import Geopandas in a process results in ModuleNotFoundError: No module named 'geopandas'.

Steps to Reproduce

  1. Add docker volume mount for a custom process module that contains import geopandas in /pygeoapi/pygeoapi/process
  2. Start the Pygeoapi Docker image with the volume mount.

Expected behavior
Geopandas should be imported, because it is included in requirements-provider.txt.

Environment

  • pygeoapi version: Docker image 0.22.0.

Additional context
My general question is, should all the requirements-provider.txt Python modules also be available in the Docker image, as I am assuming?

The current test workflow builds and runs the tests with a docker image that installs all Python requirements, including requirements-provider.txt:

https://github.com/geopython/pygeoapi/blob/master/.github/workflows/main.yml#L126

The current docker image publishing workflow, however, does not install all the Python requirements:

https://github.com/geopython/pygeoapi/blob/master/Dockerfile#L132

It seems that many of the other requirements when building the docker image are installed, not with pip, but from Debian packages:

https://github.com/geopython/pygeoapi/blob/master/Dockerfile#L62

Furthermore, there seems to be a difference between the packages that are installed with apt-get (when building the docker image) vs. the packages that are installed with pip (when running the tests).

The geopandas dependency has been added with the parquet provider, but the PR adding the dependency (#1722) does not add the corresponding dependency to the Dockerfile deb_packages list.

So, the general question becomes:

  1. should the Docker image contain all the dependencies that are listed in the requirements files, or is it by design more limited in scope, OR

  2. should the dependency management of the Dockerfile be integrated with that of the test workflow, so that we can be assured that all the tested dependencies are also built into the Docker image that is published, OR

  3. have I misunderstood the above?

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions