Comment on Using source command for virtual Python environment

MajorHavoc@programming.dev ⁨2⁩ ⁨weeks⁩ ago

• 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

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

      source

      • Flamekebab@piefed.social ⁨1⁩ ⁨week⁩ 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.

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

        source
  • 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