Installation report does not include `requested_extras` if pkg referenced by path

[phaer]

Description

Hello,

While trying out the fantastic new installation report feature, I've noticed different behavior when installing packages with extras by name (i.e. Jinja2[i18n]) compared to installing them by Path (i.e. .[i18n] or /tmp/Jinja2.tar.gz[i18n].

requested_extras in the installation reports gets correctly set to [i18n] in the first case, but missing in the latter.
This seems only to affect extras in the report, the packages are installed correctly in both cases. requested: true on Jinaj2 is also set correctly in both cases.

Expected behavior

I'd expect the installation report the same w.r.t. requested_extras if the effective output, the installed packages, are the same.
i.e. the two pip install commands below should yield the same output.

pip version

23.0.1

Python version

3.10

OS

NixOS 22.11

How to Reproduce

1. Create a fresh venv
2. Do a dry-run install of Jinja2[i18n] by name
3. Do a dry-run install of Jinja2-3.1.2.tar.gz[i18n] as downloaded from pypi
4. Notice that the report generated by the first does correctly include requested_extras: ["i18n"] while the latter does not.

Output

$ mkdir -p /tmp/venv; python -m venv /tmp/venv

$ /tmp/venv/bin/pip install --dry-run --report /tmp/venv/report-with-name.json Jinja2[i18n] ; jq '.["install"][] | select(.metadata.name == "Jinja2") | .requested_extras' /tmp/venv/report-with-name.json                                                                                                                   
Collecting Jinja2[i18n]                                                                                                                                                     
  Using cached Jinja2-3.1.2-py3-none-any.whl (133 kB)                                                                                                                       
Collecting MarkupSafe>=2.0                                                                                                                                                  
  Using cached MarkupSafe-2.1.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (25 kB)                                                                          
Collecting Babel>=2.7                                                                                                                                                       
  Using cached Babel-2.12.1-py3-none-any.whl (10.1 MB)                                                                                                                      
Would install Babel-2.12.1 Jinja2-3.1.2 MarkupSafe-2.1.1                                                                                                                    
[                                                                                                                                                                           
  "i18n"                                                                                                                                                                    
]                                                                                                                                                                           
                                                                                                                                                                            
$ /tmp/venv/bin/pip install --dry-run --report /tmp/venv/report-with-path.json ~/Downloads/Jinja2-3.1.2.tar.gz[i18n] ; jq '.["install"][] | select(.metadata.name == "Jinja2") | .requested_extras' /tmp/venv/report-with-path.json                                                                                          
Processing /home/phaer/Downloads/Jinja2-3.1.2.tar.gz                                                                                                                        
  Preparing metadata (setup.py) ... done                                                                                                                                    
Collecting MarkupSafe>=2.0                                                                                                                                                  
  Using cached MarkupSafe-2.1.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (25 kB)                                                                          
Collecting Babel>=2.7                                                                                                                                                       
  Using cached Babel-2.12.1-py3-none-any.whl (10.1 MB)                                                                                                                      
Would install Babel-2.12.1 Jinja2-3.1.2 MarkupSafe-2.1.1                                                                                                                    
null                                                                             

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[sbidoul]

@phaer Thanks for reporting. I could reproduce. I'll investigate.

[phaer]

@sbidoul Thanks for the confirmation! I just started looking into writing a test to compare reports from direct installs and installs from index which could catch such problems :)

I've noticed that direct install reports seem to miss "download_info.hashes" as well.

[sbidoul]

@phaer I had just added a test (and a possible fix) for this in #11947.

Regarding download_info.hashes, if it's absent it might be due to the cache having been populated with older pip version. Please try with --no-cache to confirm. If it persists, don't hesitate to open another issue with a reproducer. It's still quite new, so there might be some remaining quirks.

[phaer]

@sbidoul Ah, great timing - i just pushed :) Thanks for your fix. The error with download_info.hashes seems to be reproducible with my test case in 31f97d4.

[sbidoul]

The error with download_info.hashes seems to be reproducible with my test case in 31f97d4.

Ah, I see. download_info with direct URLs. Good catch. I have something in the works that addresses that incidentally.

[sbidoul]

@phaer see #11948 and #11949 for hashes. These should land in 23.1.

[phaer]

@sbidoul Thanks for quick the solution!