I’ve been trying to code python on my deck and I can’t for the life of me figure out how to activate the virtual environment. I keep using “source .venv/bin/activate” and it does nothing. No errors, no feedback, doesn’t hang, doesn’t use the environment, nothing.

I’ve tried installing Kitty to see if it was an issue with Konsole but the exact same thing happens. It works fine in Visual Studio Code but I do t want to have to open that every time I try and run a command.

Anyone know why this could be or what I could do to fix it?

Edit to add: This is my first real attempt at Linux idk what I’m doing in a very broad way. Only other time I tried was nearly 15 years ago dual booting Windows/Ubuntu but that lasted like a week because Windows kept blowing up the config and I needed some Windows only programs for school

Solved edit: I don’t exactly know what was up. If I made the venv with the terminal, it would work in the terminal but not work with VSCode’s terminal. If I made it in VSCode it would work in VSCode’s terminal but not the normal terminal. I uninstalled VSCode, made the venv in the Konsole terminal, and everything seems to work fine through PyCharm instead.

  • Ms. ArmoredThirteenOPEnglish
    1·
    3 days ago

    Thank you for help with what commands to run to get more info. I’ve tried multiple virtual environments each of ones built on the command line and through VSCode and had the same results with each. The current one that I did the cat command on was built with VSCode.

    cat .venv/bin/activate

    This file must be used with “source bin/activate” from bash

    You cannot run it directly

    deactivate () { # reset old environment variables if [ -n “${_OLD_VIRTUAL_PATH:-}” ] ; then PATH=“${_OLD_VIRTUAL_PATH:-}” export PATH unset _OLD_VIRTUAL_PATH fi if [ -n “${_OLD_VIRTUAL_PYTHONHOME:-}” ] ; then PYTHONHOME=“${_OLD_VIRTUAL_PYTHONHOME:-}” export PYTHONHOME unset _OLD_VIRTUAL_PYTHONHOME fi

    # Call hash to forget past locations. Without forgetting
# past locations the $PATH changes we made may not be respected.
# See "man bash" for more details. hash is usually a builtin of your shell
hash -r 2> /dev/null

if [ -n "${_OLD_VIRTUAL_PS1:-}" ] ; then
    PS1="${_OLD_VIRTUAL_PS1:-}"
    export PS1
    unset _OLD_VIRTUAL_PS1
fi

unset VIRTUAL_ENV
unset VIRTUAL_ENV_PROMPT
if [ ! "${1:-}" = "nondestructive" ] ; then
# Self destruct!
    unset -f deactivate
fi

    }

    unset irrelevant variables

    deactivate nondestructive

    on Windows, a path can contain colons and backslashes and has to be converted:

    if [ “$OSTYPE:-}" = “cygwin” ] | [ "${OSTYPE:-” = “msys” ] ; then # transform D:\path\to\venv to /d/path/to/venv on MSYS # and to /cygdrive/d/path/to/venv on Cygwin export VIRTUAL_ENV=$(cygpath /home/deck/Repos/PysidianSiteMaker/PysidianSiteMaker/.venv) else # use the path as-is export VIRTUAL_ENV=/home/deck/Repos/PysidianSiteMaker/PysidianSiteMaker/.venv fi

    _OLD_VIRTUAL_PATH=“$PATH” PATH=“$VIRTUAL_ENV/“bin”:$PATH” export PATH

    unset PYTHONHOME if set

    this will fail if PYTHONHOME is set to the empty string (which is bad anyway)

    could use if (set -u; : $PYTHONHOME) ; in bash

    if [ -n “${PYTHONHOME:-}” ] ; then _OLD_VIRTUAL_PYTHONHOME=“${PYTHONHOME:-}” unset PYTHONHOME fi

    if [ -z “${VIRTUAL_ENV_DISABLE_PROMPT:-}” ] ; then _OLD_VIRTUAL_PS1=“${PS1:-}” PS1='(.venv) ‘“${PS1:-}” export PS1 VIRTUAL_ENV_PROMPT=’(.venv) ’ export VIRTUAL_ENV_PROMPT fi

    Call hash to forget past commands. Without forgetting

    past commands the $PATH changes we made may not be respected

    hash -r 2> /dev/null

    which python

    /usr/bin/python

    python -m pip freeze (before source)

    aiohttp==3.9.1 aiosignal==1.3.1 anyio==4.2.0 attrs==23.2.0 btrfsutil==6.7.1 certifi==2024.2.2 cffi==1.16.0 click==8.1.7 crcmod==1.7 crit==3.18 cryptography==41.0.7 dbus-next==0.2.3 dbus-python==1.3.2 distro==1.9.0 evdev==1.6.1 frozenlist==1.4.1 h11==0.14.0 hid==1.0.4 httpcore==1.0.2 httpx==0.26.0 idna==3.6 iotop==0.6 multidict==6.0.4 nftables==0.1 packaging==23.2 perf==0.1 ply==3.11 progressbar2==4.3.2 protobuf==4.25.2 psutil==5.9.8 pyalsa==1.2.7 pyaml==23.9.0 pycparser==2.21 pyelftools==0.30 pyenchant==3.2.2 PyGObject==3.46.0 python-utils==3.8.2 PyYAML==6.0.1 semantic-version==2.10.0 smbus==1.1 sniffio==1.3.0 SteamOS Atomic Updater==0.20190711.0 steamos_log_submitter @ file:///builds/holo/holo/holo/steamos-log-submitter/src/steamos-log-submitter typing_extensions==4.9.0 yarl==1.9.4

    python -m pip freeze (after source)
    No module named pip

    • MajorHavoc@programming.dev
      2·
      3 days ago

      No module named pip is usually because I have Python earlier than 3.9ish and the vast majority of recipes expect Python 3.9 or later.

      A virtual environment that removes access to pip certainly isn’t working as desired.

      Here’s some things your outputs tell me:

      • The system version of Python has a lot of stuff installed. So using a virtual environment is definitely worth the effort.
      • Your activate script looks fine, on a casual read. (One of the problems we have ruled out is an empty activate file.)
      • Python and pip are both installed and available on your PATH, at least before you activate the virtual environment.
      • Your virtual environment is doing things - at least enough to break pip.

      Having ruled out an empty activate file, I would check on what shell is running. Your activate script expects bash - a classic - but your SteamDeck terminal could default to something else.

      I would also try tossing a 3 at the end of the Python and pip commands. In some situations it can help a missing command be found.

      Try these:

      which python
which pip
python -V
bash
which python
which pip
python -V
source .venv/bin/activate
which python
which python3
python -V
which pip
which pip3
pip3 freeze
      • Ms. ArmoredThirteenOPEnglish
        4·
        2 days ago

        Okay so I wiped the .venv that VSCode made again and this time ran the venv creation using python3 -m venv venv. It’s working with command line now but not within VSCode (running into the same issue that I had before but in reverse, so VSCode isn’t recognizing pip or other installed modules like markdown that I added in command line).

        This is starting to feel like maybe a difference in how VSCode handles the virtual environment vs the command line. When I create the venv in one it breaks the other

        Edit: Yeah idk what VSCode is up to. I uninstalled, remade the venv with Konsole, and installed PyCharm instead. Commands through Konsole and the PyCharm terminal are all working as expected now.

        Thank you for the help!

        • Flamekebab@piefed.socialEnglish
          1·
          9 hours ago

          If it’s any consolation, this is why I don’t use VSCode at work. I got sick of trying to figure out what it was playing at with regards to virtual environments. PyCharm is my go-to.

        • MajorHavoc@programming.dev
          1·
          2 days ago

          You’re very welcome! I’ve had that issue with VSCode. I tend to create my venv outside of VSCode and force VSCode to use it. I’ve had issues Usually because VSCode is very particular about where the venv folder can be (it really wants it in the root of the current open folder).

          All that said, everyone I know with a PyCharm licence likes it better than VSVcode anyway.

          Have fun! Don’t hesitate to reach out if you get stuck.

    • RedstoneValley@sh.itjust.works
      1·
      3 days ago

      I think VS Code is doing its own thing and it might be better if you create your own. It doesn’t have to be called .venv, that is just a VS Code convention.

      python -m venv myenv

      and then

      source myvenv/bin/activate

      should do it.

      Otherwise there is something wrong in your path or a weird python installation.

      python --version should give you a version number 3.4 or above, because these have venv included and need no additional pip installs