Is it possible to get access to the `realpath` of ...
# general
n
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.
e
We expose `%(buildroot)s`: https://www.pantsbuild.org/docs/options#config-file-entries I think that is all despite what the docs say.
n
Thank you!
This just reminded me of another thing. Every user has their own token for the internal PyPI proxy, which is generated by a script as part of the repo onboarding process. Right now it's hardcoded in the pants.toml for a specific user/token, and surprisingly this works, for now...As PyPI Artifactory is new here, I'm sure security measures will become more strictly enforced in the near future. The token is located in
~/.config/pip/pip.conf
for each user. Maybe this was already implicitly answered by your last reply, but can the index value in pants.toml be dynamically generated from a key/value pair in this conf file?
h
Every user can have private config overrides in
~/.pants.rc
that does require every user to maintain another file, alongside
~/.config/pip/pip.conf
But I don't see a way to interpolate a value from deep inside
~/.config/pip/pip.conf
into a toml file...
h
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
n
[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
👍 1
h
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)
e
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.
I answered a question about
%(buildroot)s
interpolation earlier today and had to look at code and this reminds me that env vars could be supported trivially - 1 line of code + docsite updates by just stuffing os.environ in the defaults dict.
🙌 1
👀 1
maybe with a prefix, like env.FOO vs straight up FOO
h
Neat! We'd need to make sure Pantsd invalidation still worked properly, but cool idea
e
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.
👍 1