custom pam

[samrose]

What kind of change does this PR introduce?

• passes in an arg to use go 1.24 since that is not the default go version we're using in nixpkgs in this flake
• packages gatekeeper by using the https://flake.parts/ pattern of creating a module with configuration for the package at nix/packages/gatekeeper.nix and then uses the package in nix/packages/default.nix

I will follow up with an explanation as to why we use this flake-parts approach soon.

The fundamental reasons are discussed at https://flake.parts/index.html

[steve-chavez]

packages gatekeeper by using the https://flake.parts/ pattern of creating a module with configuration for the package at nix/packages/gatekeeper.nix and then uses the package in nix/packages/default.nix

@samrose What's the advantage of the above compared to callPackage? Overall looks like the flake way is much more verbose.

[samrose]

packages gatekeeper by using the https://flake.parts/ pattern of creating a module with configuration for the package at nix/packages/gatekeeper.nix and then uses the package in nix/packages/default.nix

@samrose What's the advantage of the above compared to callPackage? Overall looks like the flake way is much more verbose.

@steve-chavez for what it's worth, here are the advantages to using flakes, and the flake-parts framework https://gist.github.com/samrose/a9a19b7fad0aed8fd8355bdf0b87df08

[staaldraad]

this and https://github.com/supabase/postgres/pull/1765 are directly related. I don't feel like merging the two into one version though, as the change in 1765 is pretty significant already.

[samrose]

this and #1765 are directly related. I don't feel like merging the two into one version though, as the change in 1765 is pretty significant already.

@staaldraad I personally support whatever works best for you. I only created this PR to trigger some of the tests and builds and checks that let us know things are working as desired + give a simpler way to see changs. But thought you could either use this PR, or move work as you see fit.

[samrose]

@staaldraad I believe it is the case that you are not yet ready to merge this correct?

[staaldraad]

@staaldraad I believe it is the case that you are not yet ready to merge this correct?

I'm ready, I've not been available to Shepard it through. And wanted to wait on the PG upgrade PR. 👍🏼

[samrose]

@staaldraad I believe it is the case that you are not yet ready to merge this correct?

I'm ready, I've not been available to Shepard it through. And wanted to wait on the PG upgrade PR. 👍🏼

@staaldraad not trying to be an unreasonable blocker, but checking in as we're being extra careful lately:

Do you think this has been thoroughly tested against latest release in our local infra?

[staaldraad]

@staaldraad I believe it is the case that you are not yet ready to merge this correct?

I'm ready, I've not been available to Shepard it through. And wanted to wait on the PG upgrade PR. 👍🏼

@staaldraad not trying to be an unreasonable blocker, but checking in as we're being extra careful lately:

Do you think this has been thoroughly tested against latest release in our local infra?

Great call out @samrose fully understood and you aren't being a blocker. It has been tested and it default off, the trigger for enabling it hasn't been enabled yet in the API. We can wait for Monday, I'll give it an extra set of testing

[samrose]

@staaldraad is it true that this package should not be installed on a pg 15 image?

[samrose]

@staaldraad did a rebase on develop since we have launched pg 17.6 and 15.14 since the time you started this work.

[staaldraad]

@samrose who hits the merge button on this one? 😄

[samrose]

@staaldraad I'll ping a few folks to do one last review, and we can merge on Monday, deploy on Tue