So… I can’t access any external network (aka internet 😕 ) from my CI and I was wondering if I can have the

pex

binary that pants tried to download from

<https://github.com/pantsbuild/pex/releases/download/v2.1.19/pex>

already inside my jenkins-agent image and point there using:

[pex]
executable_search_paths =  ["<PATH>"]

would that work? I just can’t have

pants

downloading anything that isnt from my private pypi.

Currently, there is no way to download other than pulling from the release page at

<https://github.com/pantsbuild/pex/releases/download/>

. Is it possible perhaps to allowlist that URL? Otherwise, would you be able to host the binaries somewhere? Or you’d want to be able to use a local file? (I’m trying to think of a wokaround for you; you’re going to hit this same issue with things like downloading Protoc or

scc

for counting code)

Sadly they won’t let me allowlist* it. Already asked and got a no-go. The solution they gave me was exactly what you said, I can host the artifact on our Nexus or use a S3 bucket.

Boo, but we’ll make it work. That’s very helpful you’re able to host it at least. I think we need to add an option for every ExternalTool (like Pex and Protoc) that lets you change the url as an advanced option Also, i think it’s time to graduate with a dedicated subpage on Proxies underneath the Troubleshooting page hehe

Yup, that probably sounds like a good idea. Maybe there are other folks out there that could benefit from

pants

but can’t use it bc of the same heavy regulated / security stuff.

Downloading from somewhere hosted is easier for us to implement, but we can do both and I’d rather solve this the right way than the easy way My concern with a local file is how to guarantee every machine has that file in the same absolute path. I suspect downloading from a stable URL is more reproducible and easier to maintain. Wdyt?

I mean, I’m fine with either. Maybe I’m not fully understanding how that

executable_search_paths

work. I thought it could be as easy as just add the

pex

binary to my CI’s PATH.

I mean, I’m fine with either. Maybe I’m not fully understanding how that

executable_search_paths

work. I thought it could be as easy as just add the

pex

binary to my CI’s PATH.

Binaries are always run from absolute paths. This is required by the Remote Execution API and important for determinism + caching. The option is only used for us to discover where those absolute paths are on your machine But okay cool, we’ll go with being able to change the URL for now

Also how would it “know” the version pattern? I’m assuming that I’d put on my

pants.toml

something like:

tools_external_url=<https://myhosted.stuff.com/artifacts/pex/>

and then it would solve to..

v…./pex

?

Yeah, we’ll use string templating like “{version}” and Pants will substitute it. Hope to have something up for you today

Oh, one other thing that I already know it’ll be chaotic is updating that

pex

version… I’ll have to submit a request and wait their goodwill.. so I’m thinking that maybe allowing to version lock will be very useful

+1. You can version lock today too. But warning that Pex is core infrastructure to the python backend so some slight risk that using an older version will break an assumption we have, meaning you can’t upgrade Pants till upgrading Pex.

Will it show me a warning that there’s a new version available? I’m thinking about

pex

updating overnight and no one being able to use pants the next day bc it’s trying to get a version that’s still not available in my hosted solution.

This would solely be an issue when upgrading to a new Pants release. It should never break overnight on you. We never use “latest”