gptel-bedrock: aws profile keyword argument

[leezu]

This extends the previous AWS_PROFILE based get-credentials implementation to allow explicit setting of the profile

[karthink]

Pinging @akssri, @felipeochoa: do you have any comments about this PR?

[felipeochoa]

Is the idea that you might have different gptel instances running different profiles? Or what does this buy over just calling setenv?

[akssri]

- You should change L534 to ```(or profile (getenv ....))``` so that envvars can be overridden. - Nit: remove whitespace edit on L632 Otherwise LGTM

On ಜುಲೈ 10, 2025 02:07:11 ಪೂರ್ವಾಹ್ನ GMT+09:00, karthink ***@***.***> wrote: karthink left a comment (karthink/gptel#925) Pinging @akssri, @felipeochoa: do you have any comments about this PR? -- Reply to this email directly or view it on GitHub: #925 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

- ಅಕ್ಷಯ -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[leezu]

@akssri added a commit to swap the precedence of argument and environment variable.

@felipeochoa users may wish to use a separate aws profile for gptel compared to other activities triggered from emacs. setenv would set the environment variable for all processes inheriting the emacs environment variables.

[akssri]

LGTM

[lgfang]

Hello, I noticed this pull request after submitting my own, (#996). Both PRs address the same goal of adding an optional :profile argument to gptel-make-bedrock, but they do so with a couple of key differences.

Comparison of Implementations

1. Handling of the :profile Parameter

   • This PR: Passes the :profile value down through the function call chain.
   • My PR (gptel-bedrock: allow configuring AWS profile via gptel-make-bedrock #996): Retrieves the :profile value directly from the gptel-backend variable within the get-credentials function.

   In my opinion, the approach in my PR is a bit more concise as it avoids passing the parameter through intermediate functions.

2. Credential Lookup Order

   The order in which AWS credentials are sourced is also different. This can affect which credentials are used if multiple sources are configured.

   • This PR's Order:

     1. The AWS_ACCESS_KEY_ID and related environment variables
     2. The :profile value provided in the backend configuration.
     3. The AWS_PROFILE environment variable.

   • My PR's (gptel-bedrock: allow configuring AWS profile via gptel-make-bedrock #996) Order:

     1. The :profile value provided in the backend configuration.
     2. The AWS_ACCESS_KEY_ID and related environment variables
     3. The AWS_PROFILE environment variable.

   My implementation prioritizes the explicitly configured :profile over the general environment variables, which might be a more expected behavior for users who set a specific profile for gptel. The description in my PR contains the detailed reasoning for this credential order.

I'm happy to discuss these differences and consolidate our efforts. Thank you for your work on this

[akssri]

(Moved to #1053)

[karthink]

Closing in favor of #1053.