3 ms·

This is why I still like to setup projects and environments with my own `make` `venv` and `pip`.

• UqWBcuFx6NV4r 7mo ago
  No it’s not. You do it because you didn’t see the point in changing what you do. Don’t pretend that this is your “I told you so” moment. The QOL improvement offered by uv over your approach is certainly substantial, but it’s also easy to get off of uv. Nobody here feels legitimately “trapped” in the uv “ecosystem”. For 99.999% of Python projects, if they need to get off of uv, it’s going to be a very quick thing to do. The disappointment and anger is because we’ve had a nice QOL improvement which is now more directly threatened in a way that it was before, and it’s always hard to go backwards. A QOL improvement that you never had in the first place. So…congrats? Unless your point is “this is why I deprive myself of nice things, because they can go away”…which is just silly.
  • ddxv 7mo ago
    Yes, I think we are mostly in agreement. I tried `uv` several times and never wanted to add it as a dependency because I wasn't convinced by the QOL. That being said, the biggest concern I always had was just that it was adding another layer of complexity and similar to Conda or pyenv it just wasn't something I was going to like. I probably did come off a bit 'told you so' but I guess it was more that it felt like this was finally an answer to a question/curiosity I've had about `uv` where I didn't understand the dissonance between how others felt about it and how I did.
• JackSlateur 7mo ago
  Hopefully, you are writing PEP621-style pyproject.toml, yes ? Then replacing uv with poetry or probably other thing is easy, because this is the standard packaging format