Upgrade to Postgres 14, change client library setup (#381) #382
Conversation
|
This looks good. Did you change from the binary to source because of the installation notes or some other reason? Does it add much time to the compilation? Would you know why these packages are separate and not just in the requirements.txt? Only reason I can think of is so they'll be cached in a separate layer. |
| @@ -22,10 +22,11 @@ services: | |||
| - webpack_watcher | |||
|
|
|||
| database: | |||
| image: postgres:10.4-alpine | |||
| image: postgres:14.4-alpine | |||
There was a problem hiding this comment.
I'd like to move off of alpine but we aren't changing anything and it isn't used in the deployment, I think it's fine to stay on alpine here. But if we ever upgrade the node dependency in the Dockerfile, I'd switch that over to the node:##-slim tag.
There was a problem hiding this comment.
What's the downside to alpine? Just curious.
@jonespm, I was having issues with the binary file after the upgrade. I thought it might be because of M1, but I'm not sure. Do you have time to change it back and remove the the linux package to see what happens? I'd be curious if you also see issues. It does seem to be recommended that you use this approach, but this isn't something I'm very knowledgeable about.
I asked James about this a while ago; I think his rationale was that the database and server libraries shouldn't be coupled to the rest of the application, since some of them could be swapped out or a different |
|
That makes sense the binary may not work. I also noticed that the psycopg package has a newer version released at 3.1.8. This 2.9.5 is from 10/2022. They have a slightly different way of installing this, either as Perhaps this is more of an upgrade for when we actually do upgrade the dependencies in #383 |
|
@jonespm, Django says to use |
|
I see, looks like it's going to be supported in Django 4.2, but there was a lot of work involved. |
This PR aims to resolve #381.