Oh man trying to get Pants to work well with CodeArtifact is PAINFUL.. • Pex uses

--isolated

so no support for the "recommend" AWS way for having

aws

CLI set

pip

config file. ◦ Therefore you have to use the Env Var method: ▪︎

export CODEARTIFACT_AUTH_TOKEN=aws codeartifact get-authorization-token --domain ...

▪︎ Then use the index URL:

<https://aws>:$CODEARTIFACT_AUTH_TOKEN@<URL>/pypi/pypi-store/simple/

• That relies on your terminal expanding the env var. Therefore https://www.pantsbuild.org/docs/reference-python-repos#indexes won't work ◦ In fact, I can't find any way to get this working. I think I just can't run

generate-lockfiles

. I'll have to lock manually • For downloading, I also can't seem to get the auth env var working. Again, the index is passed as

$CODEARTIFACT_AUTH_TOKEN

verbatim. Even removing that, I keep getting 401 Unauth errors ◦ This is even with

[subprocess-environment].env_vars = ["CODEARTIFACT_AUTH_TOKEN"]

. I'm running in the sandbox directly to test it out. So, that's a brick wall. This also doesn't touch on the asinine timeout AWS tokens have at a maximum of 12 hours. But that's not Pants' fault (although Pants could do a sneaky sneaky to refresh the env var)

I was going through pants though

export PIP_EXTRA_INDEX_URL="<https://aws>:${CODEARTIFACT_AUTH_TOKEN}@<org>-<account_id>.d.codeartifact.<region>.<http://amazonaws.com/pypi/<repo>/simple/|amazonaws.com/pypi/<repo>/simple/>"
export PANTS_PYTHON_REPOS_INDEXES="+['${PIP_EXTRA_INDEX_URL}']"

I see, yeah OK that makes sense. Although that means changing the config with every re-auth. And changing the commandline args passed to Pex each re-auth. So double-whammy of caching.memoization

yeah

well I literally just hit this problem and I’m glad it sounds like there’s a solution, but my hope for fixing it dropped as I’m sure you’re both much smarter than me 😄

Yeah what @refined-addition-53644 will unblock the overall,. but has nasty side-effects 😕

is there anything else required other than just exporting those env vars?

You will have to have a valid

CODEARTIFACT_AUTH_TOKEN

every time you want to run pants.

Ah, this might make it better? At least the daemon restarting: https://github.com/pantsbuild/pants/issues/12178 I think the process cmdline args issue is still relevant

Yeah exporting the env variable worked for us too. Though it would be nice if we could somehow configure pants with it or maybe read it from a file somewhere.

Hey @bitter-ability-32190! Curious if you had any luck with getting Code Artifact to play nice with caching? Our CI runs on spot instances so basically every build means a different

CODEARTIFACT_AUTH_TOKEN

so pants ends up rebuilding all of our pex binaries every run instead of pulling them from our remote cache

We're not using code artifact, so I won't be that helpful. FWIW we forked Pex to inject some behavior so you could do that. Also John mentioned somewhere in this slack that he was going to ask a feature to Pex that (and I'm having trouble remembering the details) might help here. Something about allowing Pex to read the pip config perhaps?

No worries! Appreciate the response on a 4 month old thread :)) Yes! I was looking at that PR last night https://github.com/pantsbuild/pex/pull/2243 looks like it's available from PEX 2.1.147. Now to figure out how to have Pants include the

--use-pip-config

flag in every PEX invocation. Also in case anybody else comes across this thread, I ran into this project https://github.com/sktan/aws-codeartifact-proxy which could be another solution for folks who don't mind adding another piece of infrastructure

If there's and ENV var equivalent in PEX, that's an option. Otherwise yeah I suppose it'd take a PR to Pants to allow people to opt-in

Hello @bored-soccer-37961, any luck finding a simpler setup?

I have similar issues but the behavior isn’t consistent enough for me to know for sure.

Hey @gentle-flower-25372, we deployed https://github.com/sktan/aws-codeartifact-proxy for our CI and we get much more test cache hits!

Interesting idea. We have a bunch of runners and I wonder if deploying it on each dedicated runner would increase cache hits.

We deployed it once for all runners, but yeah same principle

do you get users to point to your proxy, or do you present the proxy and hijack default pypi traffic?

Our pypi URL in pants.toml points to a proxy that lives in our dev/engineering VPN. The CI workers are not in that VPN, but we override the dns entry in the CI workers network to point to a CI-specific proxy