https://pantsbuild.org/ logo
Join Slack
Powered by
Hello :wave: I am having a problem with authentica...
# general
a
Hello šŸ‘‹ I am having a problem with authenticated PyPI indexes on pants versions 
2.21.0
and 
2.22.0a0
The following changes fix the problem (i.e. lockfiles are generated as normal): ā€¢ set 
pants_version = "2.20.0"
in 
pants.toml
ā€¢ configure the PyPI repo to not require authentication As an MWE, I cloned the example-python repo, and added the following to `pants.toml`:
Copy code
[python-repos]
indexes = [
  "http://%(env.PYPI_USERNAME)s:%(env.PYPI_PASSWORD)s@%(env.PYPI_PATH)s",
]
I have verified that this works directly with 
pip
when passed via 
--index-url
(and 
--trusted-host
). Running 
pants --keep-sandboxes=on_failure generate-lockfiles
fails with the following output:
Copy code
12:50:02.79 [INFO] Initializing scheduler...
12:50:05.87 [INFO] Scheduler initialized.
12:50:10.98 [INFO] Preserving local process execution dir /tmp/pants-sandbox-bvPGIm for Generate lockfile for python-default
12:50:10.98 [INFO] Completed: Generate lockfile for python-default
12:50:10.98 [ERROR] 1 Exception encountered:

Engine traceback:
  in `generate-lockfiles` goal

ProcessExecutionFailure: Process 'Generate lockfile for python-default' failed with exit code 1.
stdout:

stderr:
Pin(project_name=ProjectName(raw='py', validated=False, normalized='py'), version=Version(raw='1.11.0', normalized='1.11'))
If I add 
-vvv
to the pex command in the sandbox's 
__run.py
I get the additional traceback:
Copy code
Traceback (most recent call last):exing downloads                                                                        
  File "/home/neil/.cache/pants/named_caches/pex_root/installed_wheels/8d43c1ed16877f3d2ed39e5ef3e92aa8885d4427cd7d9ce62683c922a5c0cd07/pex-2.3.1-py2.py3-none-any.whl/pex/result.py", line 105, in catch
    return func(*args, **kwargs)
  File "/home/neil/.cache/pants/named_caches/pex_root/installed_wheels/8d43c1ed16877f3d2ed39e5ef3e92aa8885d4427cd7d9ce62683c922a5c0cd07/pex-2.3.1-py2.py3-none-any.whl/pex/cli/command.py", line 110, in run
    return subcommand_func(self)
  File "/home/neil/.cache/pants/named_caches/pex_root/installed_wheels/8d43c1ed16877f3d2ed39e5ef3e92aa8885d4427cd7d9ce62683c922a5c0cd07/pex-2.3.1-py2.py3-none-any.whl/pex/cli/command.py", line 102, in _check_no_passthrough_args_and_run
    return subcommand_func(self)
  File "/home/neil/.cache/pants/named_caches/pex_root/installed_wheels/8d43c1ed16877f3d2ed39e5ef3e92aa8885d4427cd7d9ce62683c922a5c0cd07/pex-2.3.1-py2.py3-none-any.whl/pex/cli/commands/lock.py", line 851, in _create
    create(
  File "/home/neil/.cache/pants/named_caches/pex_root/installed_wheels/8d43c1ed16877f3d2ed39e5ef3e92aa8885d4427cd7d9ce62683c922a5c0cd07/pex-2.3.1-py2.py3-none-any.whl/pex/resolve/lockfile/create.py", line 428, in create
    create_lock_download_manager = CreateLockDownloadManager.create(
  File "/home/neil/.cache/pants/named_caches/pex_root/installed_wheels/8d43c1ed16877f3d2ed39e5ef3e92aa8885d4427cd7d9ce62683c922a5c0cd07/pex-2.3.1-py2.py3-none-any.whl/pex/resolve/lockfile/create.py", line 99, in create
    artifact_and_project_name = source_artifacts_by_pin[pin]
KeyError: Pin(project_name=ProjectName(raw='py', validated=False, normalized='py'), version=Version(raw='1.11.0', normalized='1.11'))
Using 
--preserve-pip-download-log
in the pex command, it appears pip is able to access the authenticated repo no problem; the log file concludes with:
Copy code
2024-06-11T12:56:52,578 Successfully downloaded ansicolors pytest setuptools types-setuptools attrs pluggy py tomli iniconfig packaging
I'd be grateful for any help debugging further šŸ™
FWIW, I get the same error if I force 
pants_version = "2.21.0"
to be run with the pex version that 
pants_version = "2.20.0"
uses (with the caveat that this is an unsupported combination)
h
Hm... does this work against unauthenticated regular PyPI? It looks like all those packages should be available there?
a
Yes works against regular unauthenticated PyPI Also works against my own private PyPI if I enable unauthenticated access and don't pass credentials
To me it looks like it is accessing my authenticated repo just fine, then something happens post download which causes the error
h
I'm surprised that Pants 2.21.0 fails on the same version of Pex that Pants 2.20.0 succeeds with, since this seems like an issue happening inside Pex.
BTW thanks for doing all the great debugging you mentioned!
Getting into the sandbox and isolating the process is extremely helpful
So first, I want to double-check that you indeed forced Pants 2.21.0 to run with Pex v2.2.1 and the error happened but did not happen with Pants 2.20.0 + Pex v2.2.1?
You can verify in the sandbox by running pex (as in 
__run.sh
) but with 
--version
instead of the args hardcoded via 
__run.sh
(or rather the script that thing runs - you'll have to do a tiny bit of spelunking)
Another useful next step is a repro. Are you able to run a temp instance of the PyPI server that we can connect to over the public internet, but that does require auth that you can give us temp creds for?
a
BTW thanks for doing all the great debugging you mentioned!
No problem - thanks for taking the time to help I'm taking a look at the steps you have suggested now
I want to double-check that you indeed forced Pants 2.21.0 to run with Pex v2.2.1 and the error happened
Can confirm this, yes - 
--version
gives me 
2.2.1
but did not happen with Pants 2.20.0 + Pex v2.2.1?
Can also confirm this - forcing the pex version to remain the same and dropping the pants version down a minor level fixes the error
h
That is strange
so next step would be to compare the inputs to the pex processes in both cases
There would have to be some difference there
Easiest way to do that is in the sandboxes
a
The only change is that Pants 2.20.0 uses 
--pip-version 23.1.2
and Pants 2.21.0 uses 
--pip-version 24.0
ah and if I remove the Pex version constraint for Pants 2.21.0 but enforce 
python.pip_version = "23.1.2"
then everything works as expected
The problem appears to happen for pip >= 23.3.1
Pex have acknowledged a problem with these versions of pip: https://github.com/pex-tool/pex/releases/tag/v2.3.3 However using this version of Pex doesn't solve the problem at hand
Heading home now, I will pick this back up tomorrow
h
Ah yes, the issue pex fixes there is of the lockfile containing the wrong URLs, but not of a crash when computing the lockfile. So my guess is there is a bug in that new logic.
10 Views
Open in Slack
PreviousNext
Powered by