Bump postgresql client to version 16 #138
Conversation
|
I've seen a PR on GDAL that updates its base image to Ubuntu 24.04 LTS. I don't know if that will end up/has ended up in what will be GDAL 3.9.0, but that would give a more recent Postgres client by just changing the version number like you've done. Edit: GDAL 3.9.0 will use Ubuntu 24.04 as base for the Docker images (https://github.com/OSGeo/gdal/tree/release/3.9/docker). Dependabot will open a PR here to update the Dockerfile to use GDAL 3.9.0 when that is released. |
|
I think you'll need to update the base image, from here: https://github.com/OSGeo/gdal/pkgs/container/gdal That'll update Ubuntu underneath it. |
|
GDAL 3,9 is still at release candidate 2. I'll leave this as is rn and wait a bit for a full release. |
| # Cleanup | ||
| && apt-get autoclean \ | ||
| && apt-get autoremove \ | ||
| && rm -rf /var/lib/{apt,dpkg,cache,log} | ||
|
|
||
| ENV VIRTUAL_ENV /virtualenv/python3.10 | ||
| ENV PATH /virtualenv/python3.10/bin:$PATH | ||
|
|
||
| COPY requirements.txt constraints.txt version.txt /conf/ | ||
|
|
||
| RUN cat /conf/version.txt \ |
There was a problem hiding this comment.
Can't you just add --break-system-packages after install in the next few lines and skip everything else?
There was a problem hiding this comment.
I'd prefer not to as this feature in Ubuntu 24 was introduced for a reason. Other than a few extra lines of code, is there any other drawbacks from using virtualenv?
There was a problem hiding this comment.
I don't think there are any other drawbacks, but if there's only one-to-one mapping between containers and virtual environments there's no real advantage either - other than making setup the same in a containerised and non-containerised environments, which I guess is a minor win.
There was a problem hiding this comment.
Thanks @SpacemanPaul Agree that the only real tangible benefit will be consistency on how the python runtime is used between both container and non-container environments, and hopefully make code maintenance easier in the future.
| # Cleanup | ||
| && apt-get autoclean \ | ||
| && apt-get autoremove \ | ||
| && rm -rf /var/lib/{apt,dpkg,cache,log} | ||
|
|
||
| ENV VIRTUAL_ENV /virtualenv/python3.10 | ||
| ENV PATH /virtualenv/python3.10/bin:$PATH | ||
|
|
||
| COPY requirements.txt constraints.txt version.txt /conf/ | ||
|
|
||
| RUN cat /conf/version.txt \ |
There was a problem hiding this comment.
I don't think there are any other drawbacks, but if there's only one-to-one mapping between containers and virtual environments there's no real advantage either - other than making setup the same in a containerised and non-containerised environments, which I guess is a minor win.
| # Cleanup | ||
| && apt-get autoclean \ | ||
| && apt-get autoremove \ | ||
| && rm -rf /var/lib/{apt,dpkg,cache,log} | ||
|
|
||
| ENV VIRTUAL_ENV /virtualenv/python3.12 | ||
| ENV PATH /virtualenv/python3.12/bin:$PATH | ||
|
|
There was a problem hiding this comment.
Do we need to set these manually? Isn't sourcing the activate script sufficient? Or does the way Docker uses intermediate containers break that approach?
There was a problem hiding this comment.
I guess if it's passing tests it's probably OK.
Bumping postgresql client to a later version. Official documentation notes that psql is backwards compatible.
"If you want to use psql to connect to several servers of different major versions, it is recommended that you use the newest version of psql. Alternatively, you can keep around a copy of psql from each major version and be sure to use the version that matches the respective server. But in practice, this additional complication should not be necessary."
https://www.postgresql.org/docs/current/app-psql.html