Ignore the user-set UV_MANAGED_PYTHON

[j178]

Closes #899

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.80%. Comparing base (6df836b) to head (0a3b5d2).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #900   +/-   ##
=======================================
  Coverage   89.80%   89.80%           
=======================================
  Files          62       62           
  Lines       11552    11558    +6     
=======================================
+ Hits        10374    10380    +6     
  Misses       1178     1178           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ulgens]

Could you please give more details about the solution? This feels like a harsh workaround. I'm missing why this should be ignored if the user prefers to work with uv.

[j178]

This isn't a workaround. Prek uses uv as a library, so you can think of uv as part of prek itself. I want this component's logic to be completely controlled by prek, without any interference from external user configurations. So when prek uses uv, it should operate with completely independent cache directories and Python install directories.

Here's the issue: prek already uses --python-preference managed when calling uv. But if a user has the UV_PYTHON_MANAGED environment variable set, uv treats the command arguments as --python-preference managed --managed-python. The problem is that --python-preference and --managed-python conflict with each other (since --managed-python is equivalent with --python-preference only-managed), which causes an error.

In this case, I think it makes sense to ignore the user's UV_PYTHON_MANAGED setting.

[ulgens]

I think I mostly disagree with this part:

I want this component's logic to be completely controlled by prek, without any interference from external user configurations.

I'd expect that prek, or any other similar tool, does the minimum possible work related to the env and other tools, and respect the user preferences.

[j178]

Sorry, I take back what I said earlier - I lost my cool there. You’re totally right to be concerned, but the thing is, prek just can’t work the way you’re thinking right now. I’m definitely open to changing it though - if you anyone can figure out how to make it work.

[ulgens]

That's okay, sorry if I came too hot with the feedback. I don't have a way to contribute code right now but I'll try to support in a way I can do if I can find one.