Albert Tugushev

At the first glance these might be the fixes: 1. Override cached link by source link ```patch diff --git piptools/resolver.py piptools/resolver.py index f9d3d12..72c95d5 100644 --- piptools/resolver.py +++ piptools/resolver.py @@ -763,7...

That would be incompatible with pip itself. AFAIR we try to keep in/txt files installable via `pip install -r ...`.

I've racked down the exception, here are details below. **Stacktrace:** ```python # .venv/lib/python3.9/site-packages/pep517/wrappers.py(269) 266 # Run the hook in a subprocess 267 with _in_proc_script_path() as script: 268 python = self.python_executable...

> Moreover, I'm not sure `pep517` is at fault here. `pip` itself uses (a vendored copy of) `pep517`, but you don't get this problem with `pip wheel` or `pip install`....

Hello @Behoston, Thank you for the report! Any chance to get a report with real packages? It would help a lot.

Hello @georgek, Thanks for bringing this up! TBH I have no experience with `pipx`, but I've heard pretty much positive feedback about this project, so I think it would be...

@georgek > but the downside is it then breaks `pip freeze` Could you elaborate on why `pip-tools` would break `pip freeze`?

> One reason I thought about this is because poetry supports (and recommends) installation via `pipx`. I think it's the way to go for tools like this. Yeah, that's because...

> Calling `sys.executable` looks quite deliberate to me so I'm wondering if there are any downsides to changing it to simply `"python"`? That was part of the fix #734 issue...

`sys.executable` guarantees that you will install packages in the right virtual environment.