github action adopt uv

[darjeeling]

• adopt uv in github action to test a little faster

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.51%. Comparing base (c2f1f31) to head (bab9734).
Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #57      +/-   ##
==========================================
+ Coverage   81.30%   81.51%   +0.20%     
==========================================
  Files          23       24       +1     
  Lines         706      714       +8     
==========================================
+ Hits          574      582       +8     
  Misses        132      132              

Flag	Coverage Δ
	?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[hexoul]

Thanks for trying to improve. But I'm not sure this approach is good.
From invoked Github action jobs, there is no big difference. Meanwhile, dependency will be added and maintenance cost will be increased. uv is not de facto now.

[minwoox]

@hexoul It seems like uv is becoming the de facto. 😅
https://www.reddit.com/r/Python/comments/1ghiln0/state_of_the_art_python_in_2024/?rdt=57259

[ikhoon]

• adopt uv in github action to test a little faster

Could you share a number on how much faster the tests run?

[darjeeling]

@ikhoon
in most cases, 30 seconds faster for installation

[darjeeling]

@minwoox IMHO, we have other tools that support almost same format. so we can change other tool if it's not standard

• PEP-621
• PEP-735

[minwoox]

@darjeeling What I meant was, I preferred using uv. 😉

[corona10]

Well, my two cents is that using uv has more upside rather than downside.
(The only downside would be future license issues if Astral change their policy)
Since uv provides a drop-in-replacement interface with pip, there will be no issue compared to using pip unless we use a non-standard feature that is only provided by uv.

Many Python projects these days (including product engineering) begin to start using uv due to performance issue of pip, I think that we can just start to use it and replace it later if the uv makes any trouble.

But we should only use standard feature only.

[hexoul]

After taking a look more into pros/cons from many sources and arguments in the thread @minwoox referred, I weakly agreed. Except for license issue, uv looks cool and can rollback if problem occurs as @corona10 said. However, performance issue from pip is not sensitive in this project and there are ongoing discussions. So, adopting uv makes sense, but can we say that now is good time to apply?

[minwoox]

performance issue from pip is not sensitive

Right, we don't have any performance issues with pip because this project is relatively small.
It's just that uv is getting popular, and since we can always revert it so, there was no reason not to give it a try.
Since you're maintaining this repository, it's your call. I will go along with whatever decision you make. 😉

[ikhoon]

Thanks @darjeeling for your interest and contribution to centraldogma-python. This project is mostly maintained by contributing @hexoul personal effort. I don't want to use his resources aside from bug fixes and new features.

If there is a problem with CI builds, we need to fix it. However, if we simply want to try it out, I think it's not too late to do it the next time we feel a problem in pip.

[hexoul]

Thanks for all comments, supports and considerations. Let us try.