Using source command for virtual Python environment

Comments

• saffroncity@lemmy.world ⁨2⁩ ⁨weeks⁩ 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.

  source
• Fubarberry@sopuli.xyz ⁨2⁩ ⁨weeks⁩ 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.

  source

  • ArmoredThirteen@lemmy.zip ⁨2⁩ ⁨weeks⁩ ago

    I’m using Konsole, seems to be the default terminal for me

    source

    • Fubarberry@sopuli.xyz ⁨2⁩ ⁨weeks⁩ 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). 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.

      source

      • -> View More Comments
• MajorHavoc@programming.dev ⁨2⁩ ⁨weeks⁩ 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?

  source

  • ArmoredThirteen@lemmy.zip ⁨2⁩ ⁨weeks⁩ 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

    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

    source

    • MajorHavoc@programming.dev ⁨2⁩ ⁨weeks⁩ 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
      

      source

      • -> View More Comments
    • RedstoneValley@sh.itjust.works ⁨2⁩ ⁨weeks⁩ 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

      source