added pyenv shell instruction

[Netherquark]

Description

originally, the venv instruction would initialise a venv with the system Python version, which breaks the installation. adding the shell command fixes this.

Screenshots/videos:

Checklist:

• I have read contributing wiki page
• I have performed a self-review of my own code
• My code follows the style guidelines
• My code passes tests

[w-e-w]

WTF what you clone the wiki and make a PR of it??????

[Netherquark]

I wasn't sure how I should edit it, sorry for the mistake. Would appreciate guidance on how I can contribute to the wiki.

[w-e-w]

We used to public editing of the wiki and you will see a edit button on the wiki page
but someone says something about search engines like google dose not indexing if the wiki is publicly accessible
and so is limited to only collaborators

and unfortunately GitHub does not support PR to the wiki
we have considered creating an automated workflow to make it possible to make PR to a different repository and automatically push it to the Wiki page
but no one has yet invest time yet to see how to make such a workflow

I don't use pyenv my self so I cant comferm if your edit command is good or not
I'll ask other to see if you change wiki is correct if so I can make the change for you

[Netherquark]

thank you so much for the prompt response! sorry once again for the inconvenience.

[w-e-w]

reading the docs I don't understand
https://github.com/pyenv/pyenv/blob/master/COMMANDS.md#pyenv-local
why isn't pyenv local enough?

pyenv local 3.10.6

Sets a local application-specific Python version by writing the version name to a .python-version file in the current directory. This version overrides the global version, and can be overridden itself by setting the PYENV_VERSION environment variable or with the pyenv shell command.

did you perhaps use pyenv shell x.x.x your self and so now the local and so is overriding the local command?
if so then I think this is a more of a "your issue"
if we tell people to run pyenv shell 3.10.6 it will just cause issues with people who uses pyenv

[Netherquark]

running the venv command after pyenv local 3.10.6 initialises a 3.12.2 (system python) venv for me. Here's my system information:

System:
  Kernel: 6.8.2-201.fsync.fc39.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 2.40-14.fc39 clocksource: tsc avail: hpet,acpi_pm
    parameters: BOOT_IMAGE=(hd0,gpt8)/vmlinuz-6.8.2-201.fsync.fc39.x86_64
    root=UUID=<filter> ro quiet splash resume=UUID=<filter>
  Console: pty pts/1 wm: gnome-shell DM: GDM v: 45.0.1 Distro: Nobara Linux
    39 (GNOME Edition) base: Fedora 39
Info:
  Packages: pm: dpkg pkgs: 0 pm: flatpak pkgs: 37 Compilers: clang: 17.0.6
    gcc: 13.2.1 Shell: Sudo (sudo) v: 1.9.15p5 default: Bash v: 5.2.26
    running-in: gnome-terminal inxi: 3.3.33

the stable diffusion installer itself catches that 3.12.2 is being used and throws a warning