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.

  • saffroncity@lemmy.world
    3·
    2 days ago

    Try running which python before and after your source command. That should show where your Python executable is.

    An old teacher of mine used to say “no news is good news” in Linux, so my guess is that your command is working but doesn’t show any output.

  • Fubarberry@sopuli.xyzMEnglish
    1·
    2 days ago

    Quick question, are you using bash or another terminal? I think they Deck comes with fish preinstalled, but if I remember right I don’t think the default source command works in fish without making some other changes.

      • Fubarberry@sopuli.xyzMEnglish
        1·
        1 day ago

        Inside konsole, you can use different shells. Some common ones are bash, fish, and zsh. The deck comes with all three of those installed by default.

        You can usually tell which one you’re using by either looking at the title bar of konsole when you first open it (should say something like ~:bash – Konsole) or by running the command echo $SHELL

        Once you’ve confirmed you’re using bash, run which python (or which python3 if you’re using python 3). Outside of the venv you should see the command return /usr/bin/python

        After you run your source command, run which python again. You should now see that the python location being run has changed to be inside the venv folder.

        • MrMcGasion@lemmy.world
          2·
          20 hours ago

          With SteamOS being Arch-based you shouldn’t ever really need to specify python3. Python 2 has been EOL for 5 years now, and the python command almost always points to python3 (unless you deliberately change it).

  • MajorHavoc@programming.dev
    1·
    2 days ago

    Some questions that would help folks help you debug:

    • What is the output of cat .venv/bin/activate?
    • What are the results of which python both before and after running the source command?
    • What are the results of python -m pip freeze both before and after running the source command?

    Oh, and a Python pro tip - when a virtual environment misbehaves in any way, I’m pretty quick to rm -rf .venv and rebuild it, in case I did something I forgot about. (If I’ve run more than 5 commands and my venv isn’t behaving as expected, I figure I am way off track.)

    • Ms. ArmoredThirteenOPEnglish
      1·
      2 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·
        2 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
          3·
          23 hours 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!

          • MajorHavoc@programming.dev
            1·
            15 hours 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·
        2 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