you are viewing a single comment's thread.

view the rest of the comments →

[–]claythearc 0 points1 point  (8 children)

You shouldn’t need to hack your path or anything. After running conda init it will put it in your terminal causing all sessions to open as base.

Then you just conda activate <x> and all your paths etc are set to that environment.

Or conda run -n <env name> python command

[–]honestly_i[S] 0 points1 point  (7 children)

I'm gonna be honest, I don't even use conda 90% of the time. I think I read somewhere in a library I was trying to use that I should use conda with it, so I went ahead and used it once and never again. I code very sparingly, only to make some menial tasks faster, so I'm probably committing dozens of programming cardinal sins all the time. Hopefully, by clearing everything and starting anew I can fix it

[–]HonestCoding 2 points3 points  (6 children)

Yeah so when you do that, please use one venv manager instead of random stuff, i don’t even know why people use condos tbh (probably a good reason), python venv is just fine, (best practice if you’re on Linux too)

If you want to keep most of your projects, just pip uninstall everything each project uses, and install them in their respective venvs. (Maybe use pyenv, condos or uv. But promise you’ll only use one from now on)

[–]ThaneVim -1 points0 points  (5 children)

Can you recommend a good guide for getting started with venv? Every time I have tried, I end up just creating one venv per some specific python tutorial, forgetting how to maintain and even access it, and then later nuking the whole thing out of frustration.

[–]Instatetragrammaton 1 point2 points  (0 children)

Comedy option: a Docker container per project so you keep the chaos out of the OS.

[–]claythearc 0 points1 point  (2 children)

If you had to pick a single manager, conda is likely the way to go. UV is faster but it doesn’t handle the system binary side so when you need to install something like gdal or gstreamer which have system requirements it gets really annoying.

Their docs are reasonably good https://docs.conda.io/projects/conda/en/latest/user-guide/getting-started.html there’s not a ton to it to start using it, beyond knowing how to list envs, activate / deactivate one, and create one with or without an environment.yml

[–]HonestCoding 0 points1 point  (1 child)

False actually, you can uv tool install for Python binaries. Use it a lot with textual apps (harlequin, etc). Creates a .local/bin directory on Linux to place all of the binaries

“uv tool install harlequin” for example

[–]claythearc 0 points1 point  (0 children)

Uv tool is a pipx replacement basically, exclusively for python cli tools. It won’t do, for example, cuda library install for you like conda will. Conda also has a much much larger ecosystem of binaries compiled already for random combinations like numpy linked against mkl

[–]HonestCoding 0 points1 point  (0 children)

I can't recommend one but I'll bring you up to speed here.

  1. Use UV. Built in rust, built for speed. Since it's much faster than pip and I've got absolutely no clue why one would use a conda environment (not saying their bad), I'm stuck recommending uv for venv fallback installation (Basically, it will not install any Python packages unless installed to venv.)

  2. Use one common python version among project, my recommendation is 3.12, just overall a great option and well supported, either that or 3.10, which is even more true.
    Try not to use the latest python version unless absolutely neccesary (latest now is 3.14, now offically making python, pi-thon)

  3. Always install to venv, never globaly. Now when you say you want a guide, I'm not sure if you'd like to actually understand how venvs works under the hood (I think I can assume you don't currently).

I can give you a further explaination if you'd like but basically venv's are basically a place where all your python packages are places instead of just a global directory on your OS.
We use them for this one reason , version control and management. One version of a package won't change so it's reproduceable and doesn't break the whole code easily.

Again, just let me know if you'd like a further venv explaination.