Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Kent Brockman
    @KentBrockman

    hey all. I've got some beef between pyenv and ansible. I understand where the problem is coming from, but I'm unsure how to fix it. Looking for some ideas. Some details:

    ansible is being installed from my system package manager (im on pop os 20.04, based off ubuntu 20.04) to /usr/bin. pyenv is installed to ~ using the github checkout method.
    Now, when I run eval "$(pyenv init -)" pyenv modifies my PATH to use the shim'd python executable before system python. this is what is is supposed to do. but now when i execute ansible, I get this error: ModuleNotFoundError: No module named 'ansible' - which is totally understandable as ansible isn't installed to pyenv's python environment.

    my question is...how should I manage this? is there a way to 'force' ansible to use the system python install? is there a way to set pyenv init - to append ~/.pyenv/shim to PATH instead of prepending it? this allows the shebang in the ansible system install script to work properly...but i suppose this is nonideal because it exposes system python in some way. should I just suck it up and setup an ansible virtualenv/pyenv environment and just use that?
    is there a simple solution to all of this that I'm not seeing?

    Philippe Ombredanne
    @pombredanne
    Personally when I use pyenv I do not use system Python or something that depends on it
    When I use Ansible with a pyenv Python, I install ansible in a virtualenv in that "virtual" Python env
    Kent Brockman
    @KentBrockman
    thanks for the insight @pombredanne. Sounds like that may be the way to go
    Maybe the way to go - remove eval "$(pyenv init -)" from my startup scripts altogether. and only call it when im working on a python project. then use system python most of the time. certainly a bit annoying but an option.
    Philippe Ombredanne
    @pombredanne
    I have the shim on at all times. But I am using the system python at most times too
    Most distros get itchy if you do a switcheroo on their beloved python version
    Kent Brockman
    @KentBrockman
    @pombredanne oh interesting. are you accessing system python through a shim?
    Philippe Ombredanne
    @pombredanne
    pyenv local system :)
    Kent Brockman
    @KentBrockman

    ah i see

    > pyenv shell system
    pyenv: system version not found in PATH

    For me though :( my distro doesnt ship a python executable anywhere in the path like /usr/bin
    ships with /usr/bin/python3 and /usr/bin/python2 though

    Thanks for the trick nonetheless :)

    Philippe Ombredanne
    @pombredanne
    @KentBrockman IMHO your pyenv installation is damaged
    reinstall
    Kent Brockman
    @KentBrockman
    @pombredanne why do you think that? seems to be working expectedly and pyenv doctor looks OK as well
    Kent Brockman
    @KentBrockman

    to expand on the above @pombredanne - if create a system python link like so sudo ln -s /usr/bin/python3 /usr/bin/python
    Now i get this

    ❯ pyenv shell system
    ❯ which python
    /home/kent/.pyenv/shims/python
    ❯ pyenv which python
    /usr/bin/python

    Is that unexpected behaviour?
    Now whether or not it is smart or safe to manually make that link in /usr/bin is a whole other issue....
    Unsure what is the indicator here that pyenv is buggered up

    That and that I reinstalled earlier this morning
    Burak Can Kahraman
    @burakcank

    For me though :( my distro doesnt ship a python executable anywhere in the path like /usr/bin
    ships with /usr/bin/python3 and /usr/bin/python2 though

    Just symlink python to python2 or python3 based on your preference.

    Oh sorry didn't see the next post.
    If there wasn't any python link before, it shouldn't be an issue.
    Philippe Ombredanne
    @pombredanne
    it is uncommon not to have a /usr/bin/python
    Burak Can Kahraman
    @burakcank
    ❯ pyenv shell system
    ❯ which python
    /home/kent/.pyenv/shims/python
    ❯ pyenv which python
    /usr/bin/python

    Is that unexpected behaviour?

    This is how I use pyenv too, seemed like totally fine to me. You access system python through a shim.

    Kent Brockman
    @KentBrockman
    thanks for the tips guy...seems like that one is the winner for sure
    and yeah philippe I agree. this seems to be a common thing in ubuntu (common enough that theres a whole package for...applying this symlink tweak: https://ubuntu.pkgs.org/20.04/ubuntu-main-armhf/python-is-python3_3.8.2-4_all.deb.html
    @burakcank I seem to be missing a system pip install as well...do you symlink /usr/bin/pip3 ?
    Burak Can Kahraman
    @burakcank
    No I do actually have pip, not the symlink but that's the way to go for you apparently.
    Kent Brockman
    @KentBrockman
    alright
    Philippe Ombredanne
    @pombredanne
    :)
    Yan Wong
    @hyanwong
    I'm trying to run a python version within the gdb debugger, that's been compiled by pyenv on OS X with the --debug flag: pyenv install --debug 3.9-dev. But when I run sudo gdb /path/to/.pyenv/versions/3.9-dev-debug/bin/python3.9d I get
    Reading symbols from /path/to/.pyenv/versions/3.9-dev-debug/bin/python3.9d...
    
    warning: `/private/var/folders/00/l36df9q14hv13hhw8wglncch0000gr/T/python-build.20201201132008.47447/Python-3.9-dev/Programs/python.o': can't open to read symbols: No such file or directory.
    
    warning: Could not open OSO archive file "/private/var/folders/00/l36df9q14hv13hhw8wglncch0000gr/T/python-build.20201201132008.47447/Python-3.9-dev/libpython3.9d.a"
    (No debugging symbols found in /path/to/.pyenv/versions/3.9-dev-debug/bin/python3.9d)
    Is this possible - I can't find any information on the web about how to do this using pyenv-installed python binaries?
    dennisetiawan23
    @dennisetiawan23
    Hello , i want to install pyenv in my school server directories
    but i dont have apt-get, or curl, and sudo access
    is this possible?
    Philippe Ombredanne
    @pombredanne
    @dennisetiawan23 this is a local, user-only install
    as long as you have the essential build and toolchain parts already installed (as well as a few common basics like zlib, bzip2, xz and a few similar)
    Try it :)
    @hyanwong if I were trying to debug a Python interpreter, I would likely build myself
    Yan Wong
    @hyanwong
    Thanks. I resorted to that, but it would be nice not to have to!
    Philippe Ombredanne
    @pombredanne

    @hyanwong that's IMHO a too exotic and rare a use case to ever support this

    If you are in a state advanced enough that you are debugging an interpreter, you should not need any of pyenv IMHO

    Dilum Aluthge
    @DilumAluthge
    I'm trying to build Python 3.8.6 with Framework support on macOS, and it is trying to write to /Applications. Can I instead write to a different folder, e.g. ~/Applications or something like that?
    I found this issue (pyenv/pyenv#1468) with the same request, but there is no answer there.
    Nafiul Islam
    @gamesbrainiac_twitter
    Folks, any idea when python 3.10a6 is going to be installable?
    Chris Barnes
    @clbarnes
    when this PR is merged pyenv/pyenv#1839
    Ryan Delaney
    @rpdelaney
    pyenv builds break when the PYENV_ROOT path contains whitespace. Known issue?
    I get the (arguably unhelpful) error that "C compiler cannot create executables"
    Ryan Delaney
    @rpdelaney
    I am not confident I can exhaustively search the closed issues to confirm there is nothing about this in there, but if folks here think it's a bug then I will file one
    Ryan Delaney
    @rpdelaney
    Is it possible that this bug is with python? I have not attempted to build python except with pyenv
    Philippe Ombredanne
    @pombredanne
    @rpdelaney Python never liked spaces in the install path
    in general I would strongly discourage spaces in any paths :)
    Ryan Delaney
    @rpdelaney
    Yeah, unfortunately macOS defaults don't follow this
    Jerry Morrison
    @1fish2
    An empty path element can also cause build errors that are hard to debug, e.g. from a startup script that does export CPATH=foo/include:$CPATH before $CPATH gets set.