[Documentation Request]: Consider Anaconda instead of PPA for Ubuntu 24.04 LTS

[Skyedra]

Is there an existing issue for this?

• [X] I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

I recently upgraded to Ubuntu 24.04 and got tripped up by an error "RuntimeError: Torch is not able to use GPU." From reading around, it sounded like I needed to remake my venv. Unfortunately when doing this, I discovered that a python3.10 venv was needed, which was not supported out of box on Ubuntu 24.04.

The documentation currently suggests installing a PPA. This is not ideal since it introduces a system-wide change. I generally prefer not to install system-wide packages unlesss absolutely necessary, and if so, to try to install via official, well-supported sources.

Fortunately, I found a workaround, which I documented over on Ask Ubuntu here. Essentially, I use Miniconda instead of a PPA. This has the benefits of only requiring user-mode / no system-wide changes required.

Versus deadsnakes PPA which includes this prominent warning:

Disclaimer: there's no guarantee of timely updates in case of security problems or other issues. If you want to use them in a security-or-otherwise-critical environment (say, on a production server), you do so at your own risk.

Which was definitely enough to dissuade myself who is already afraid of PPA's from the current install instructions.

Would an anaconda-based (or other user-mode installation option) make sense on the documentation page?

Proposed workflow

n/a

Additional information

No response

[viking1304]

EDIT: I removed the first sentence since it was just my assumption.

I used Conda in the past, and I occasionally had problems with unavailable packages. If all required packages are available, what is written should work. However, I do not like the idea of mixing Conda env and venv since those are two different virtual environments.

If you want to use Conda, it would probably be best to disable venv properly first by changing line 22 in webui-user.sh to

venv_dir="-"

You can call your Conda env any way you want, but I would never use venv for Conda env on my system. I would be confused what it is. I would do something like this instead:

conda create -n env310 python=3.10

But, as I said, your system = your rules.

[Skyedra]

Thank you for the suggestions

I tried conda activate env310 and then setting venv_dir="-" and launching ./webui.sh. However, this seems to prevent webui.sh from managing the python environment and pulling the packages it needs. I was able to get it working using venv_dir="env310". Is that an appropriate setup, or is webui.sh not supposed to be able to manage conda envs at all?

[viking1304]

Something is not right there.

I just installed Anaconda on a macOS virtual machine and tested everything.

First, I added conda binaries to the path:

echo 'export PATH=/opt/homebrew/anaconda3/bin: $PATH > ~/. zshrc

Your path is obviously different, but everything else should be the same.

Then, I created a new conda environment with

conda create -n env310 python=3.10

To confirm it was properly created, I run

conda env list

And I saw

# conda environments:
# base env310
* /opt/homebrew/anaconda3
/opt/homebrew/anaconda3/envs/env310

Then I opened webui-user.sh and changed line 22 to be exactly like this:

venv_dir="_"

I completely removed venv from stable-diffusion-webui

Then, I activated env310 with

conda activate env310

I double-checked if env310 was enabled with

conda env list

And I got this (notice that * changed position)

# conda environments:
# base env310
/opt/homebrew/anaconda3
* /opt/homebrew/anaconda3/envs/env310

I run ./webui.sh and everything worked without any issues