Allow pip-sync to remove pip-tools when --python-executable is specified

[ncoghlan]

What's the problem this feature will solve?

I'd like to be able to remove pip-tools and the other protected packages when running pip-sync --python-executable 'path/to/other/env.

The protection makes sense when pip-sync is running in the Python environment being modified, but doesn't seem necessary when manipulating a separate target environment.

Describe the solution you'd like

pip-sync --python-executable 'path/to/other/env should allow removing pip-tools and the other protected packages from the target environment. I'd be ok with having to pass an extra option to say "no, seriously, I mean it, remove everything that isn't listed in the requirements files", but would prefer it if that wasn't necessary.

This came up due to the fact that pip-compile doesn't currently allow resolving for an environment other than the one running pip-compile (adding a --python-executable option to pip-compile is a much harder problem, but would technically eliminate my use case for this hopefully simpler proposal).

To work around this, I'd like to be able to temporarily install pip-tools, and then remove it later with pip-sync.

Alternative Solutions

Rather than running pip-sync directly, instead run python -Ic "import piptools.scripts.sync, piptools.sync; piptools.sync.PACKAGES_TO_IGNORE.clear(); piptools.scripts.sync.cli()" (with the same CLI arguments as would be passed to a direct invocation of pip-sync)

Edit: just noting #2117 as a trap to watch out for when using --python-executable with standalone Python environments.

[chrysle]

Thanks for raising this issue, sounds like a resonable proposal.

(adding a --python-executable option to pip-compile is a much harder problem, but would technically eliminate my use case for this hopefully simpler proposal)

Yup, I think that is already on the roadmap; alternatively, there is #1998 proposed, which installs pip-tools internally in a temporary venv based on the current Python interpreter; this idea originally came up in terms of pipx support.

Unfortunately, we're blocked by failing Windows tests, currently, and lack contributors who would be able and willing to investigate (my feeling is that uv cost us quite a bit of importance).

[ncoghlan]

I actually need this for Windows, so I'll take a look at the failing PR in addition to looking into my own suggestion.

[chrysle]

Thanks! Tests are also failing on main, thus are unrelated to the PR (in which I think a --python-executable option could easily be implemented). And, now, compared to two days ago, there is an additional failure on all systems...

[ncoghlan]

I didn't see a clear issue related to the CI failures, so I posted one with some notes on why test_sync is failing (as of the recent 24.1 release, pip freeze doesn't protect setuptools, distribute, or wheel on Python 3.12+): #2104

[ncoghlan]

Just noting that while I did look at the failing PR, I didn't understand the pip-tools test suite well enough to provide useful feedback on the failures.