Readit NewsIn short, you can get metadata from pyproject.toml, but (a) it can still involve executing code due to PEP 517 hooks, and (b) a malicious package would use the legacy setup.py to get their code executed.
Packj uses static+dynamic code/behavioral analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect impersonating packages (typo squatting).
What pip isn't is a workflow tool for developers, or "project manager" (terminology uv uses in its marketing; "package manager" seems to be not well enough defined to argue about). Pip doesn't install Python, create or manage virtual environments (or real ones for the separately installed Python versions), upload your packages to PyPI, view a lockfile as a way to keep track of an environment (although they have just added experimental support for creating PEP 751 lockfiles and are planning support for installing from them), do one-off runs of Python applications (by installing them in an ephemeral environment, possibly installing PEP 723 inline-specified dependencies), define or manage "workspaces", have its own `[tool.pip]` section in pyproject.toml, or possibly other things I forgot.
But it absolutely does determine the dependencies of the packages you're currently asking to install, transitively, attempt to figure out a compatible set of versions, and figure out which actual build artifacts to use (i.e., "resolve dependencies"). Its logic for doing so has even been extracted and made available as the `resolvelib` package (https://pypi.org/project/resolvelib/).
My own project, PAPER, is scoped to fix pip's problems and also do basic environment management (so as to install applications or do temporary runs). The point is to satisfy the needs of Python users, while not explicitly catering to developers. (I'll probably separately offer some useful developer scripts that leverage the functionality.)
I also, incidentally, intend to allow for this sort of prompt during the install procedure. (Although the planned default is to refuse sdists entirely.)
Using the fastapi example, it points to CVE-2024-24762 which, if you're looking at the NIST or CVE pages for it, doesn't give the clearest info for how to resolve.
Maybe consider linking to advisories in the Python Packaging Advisory Database when possible, like pip-audit does. https://osv.dev/vulnerability/PYSEC-2024-38 is a lot clearer that fastapi is affected and which version fixed the vulnerability.
Or are you saying you'd rather it leads to https://osv.dev/vulnerability/PYSEC-2024-38 rather than https://osv.dev/vulnerability/CVE-2024-24762 ?
You're right I don't vendor dependencies, and I hope to get away with it exactly because I don't have the bootstrapping problem. In practice, you want to install pipask with pipx so that the dependencies don't mess with your local environment.
That said, it's pretty uncommon to use lockfiles with pip, so I'm considering creating something like a plugin for poetry or uv, if there is demand?
But there are a lot of possible workflows around that. Some people might separately install things one at a time according to what they appear to need as they're developing, and then use `pip freeze` to create the `requirements.txt` file. Others might edit `requirements.txt` directly, and repeatedly re-create their environment based off that. Still others might involve any number of tools here, such as pip-tools (https://pypi.org/project/pip-tools/), pipenv (https://pypi.org/project/pipenv/), etc.