2 ms·
Cohesion and simplicity of use. uv init; uv add No more pip freeze, source .venv/bin/activate, deactivate bullcrap.
by wiseowise 2y ago
Cohesion and simplicity of use.
uv init; uv add
No more pip freeze, source .venv/bin/activate, deactivate bullcrap.
- mickeyp 2y agoYou don't have to 'activate' anything if you don't want to. The bin/ directory inside your venv contain the binaries and scripted entrypoints for the packages installed in your virtualenv.
- wiseowise 2y agoYeah, and I don't "have" to use Make and build systems either, but it makes my life easier and bullshit free.
- zahlman 2y agoWhy is it better if every command you use starts with `uv`? Why is it "bullcrap" the other way?
- wiseowise 2y agoIt’s not “uv” part that is important. It’s the focus on simplifying things you do thousands of times a week.
- zahlman 2y agoHow does putting "uv" in front of the commands that you use simplify them?
- wiseowise 2y agouv init; uv add requests and you automatically get environment that can be easily shared between team members with predictable locking, with no “source .venv/bin/activate” bullshit.
- zahlman 2y agoActivating the venv only changes some environment variables. You can, as explained before, use the environment's Python executable directly instead. Activation does allow other tools to use the venv without having to know anything about it. The point is that you aren't then putting `uv run` in front of every command, because you don't need to have an integrator program that's aware of the venv being there. If you had a bad experience with a different locking tool, sorry to hear it, but that has absolutely nothing to do with the venv itself nor its activation script.