Is it possible to get access to the

realpath

of the

pants.toml

(SCM root) file inside

pants.toml

file itself? We have a need to use

file://

instead of external URLs, but this only works with absolute paths. Right now we are pointing to a shared network drive, but my preference is for this to point to files checked into SCM. More generally, is there documentation of all accessible variables? I'm talking about things like

{version}

. It doesn't look like Bash or Python are available in

.toml

files.

We expose `%(buildroot)s`: https://www.pantsbuild.org/docs/options#config-file-entries I think that is all despite what the docs say.

Thank you!

Every user can have private config overrides in

~/.pants.rc

What option are you setting for the PyPI config? I think I'd only expect that to be used with the experimental

publish

goal, which iirc reads from

pip.conf

already

[python-repos]

indexes = ["..."]

The "..." is unique for each user because the URL contains their assigned API key, which is stored in their local

pip.conf

(generated by an unrelated script). We set this explicitly in

pants

(the actual command script) by reading it and passing it along as an argument to any Pip invocations Pants makes, so users can bootstrap Pants (have not tried deploying Pants as a PEX yet, which might remove this step), but I think this option still needs to be set in

pants.toml

so Pants can package

pex_binary

targets by downloading/installing their 3rdparty requirements. I think we will add a follow-on to the script that generates our internal PyPI API keys to also add this to

~/.pants.rc

I've propsed https://github.com/pantsbuild/pants/issues/10399 to add env var interpolation to

pants.toml

. I'm unlikely to have time to get to it, but help definitely appreciated if you had interest Otherwise some options are to use

.pants.rc

or env vars, e.g. add to your

./pants

script

export PANTS_PYTHON_REPOS="+[\"${FOO}\"]

(string escaping might be off there)

Yeah, pip.conf is purposely not read by Pex since Pex needs to be sure certain Pip settings are just so. Maybe Pex needs to revisit that and see what it would take to support pip.conf safely.

Neat! We'd need to make sure Pantsd invalidation still worked properly, but cool idea

Unless invalidation works in a haphazard way today for the existing interpolations, this should work no matter what values are stuffed in the defaults dict. IOW if the final values are what invalidates, we should be good to go.