This is the longest blog post I've written to date and will probably remain the longest for quite a while - although a good chunk of it is just a list of historical events. There's even more I'd like to say about the issue but it's just been too hard for me to figure out how to structure the thoughts.
The redux: for Pip's entire 16+ year history, it's attempted to provide "download only" and/or "dry run" commands with varying syntax. But when you use these on a source package, it tries to build the package anyway - which in the Python world involves arbitrary code supplied by the package author. If you wanted to build from source in order to audit the code, for example, the security purpose is already defeated this way. Whenever malware sneaks on to PyPI (perhaps as a typo-squatted package), it might inadvertently run even if you think you're taking steps to be safe about it. (This once semi-famously affected a security researcher.) Either way, you'll need to take a different approach to download the package (from the PyPI website or via its API).
The redux: for Pip's entire 16+ year history, it's attempted to provide "download only" and/or "dry run" commands with varying syntax. But when you use these on a source package, it tries to build the package anyway - which in the Python world involves arbitrary code supplied by the package author. If you wanted to build from source in order to audit the code, for example, the security purpose is already defeated this way. Whenever malware sneaks on to PyPI (perhaps as a typo-squatted package), it might inadvertently run even if you think you're taking steps to be safe about it. (This once semi-famously affected a security researcher.) Either way, you'll need to take a different approach to download the package (from the PyPI website or via its API).