Re: Help needed - - running into issues with python and its tools

On 8/5/24 14:39, o1bigtenor wrote:

Matt - if you would rather that you were not included in the address list - -
please advise.
 On Mon, Aug 5, 2024 at 8:51 AM Mats Wichmann <mats@wichmann.us <mailto:mats@wichmann.us>> wrote:
     On 8/5/24 06:48, o1bigtenor via Python-list wrote:
     > On Sun, Aug 4, 2024 at 8:49 AM Mats Wichmann via Python-list <
     > python-list@python.org <mailto:python-list@python.org>> wrote:
     >
     >> On 8/3/24 20:03, o1bigtenor via Python-list wrote:
     >>
     >>> My question was, is and will be (and the doc absolutely doesn't
    cover it)
     >>> how do I install a different version in the venv so that python
    3.11.x on
     >>> the
     >>> system is not discombobulated by the python 3.12.x in the venv..
     >>> That python 3.12 would let me run the tools needed.
     >>> (Its the how to install the next version of python that I just
    haven't
     >> been
     >>> able to find information on - - - and I would be looking for
    information
     >>> on how to install on a *nix.)
     >>
     >> To get a different Python "in" the venv, you use the version you
    want in
     >> the construction of the venv. For example:
     >>
     >>
     >> $ python3.13 -m venv new_venv
     >> $ new_venv/bin/python --version
     >> Python 3.13.0b4
     >> $ source new_venv/bin/activate
     >>
     >>
     >   "https://peps.python.org/pep-0668/
    <https://peps.python.org/pep-0668/> PEP 668, which prevents pip from
     > interacting with the OS installed python. This change has been
    done in red
     > hat and other distros too . . . "
     >
     > similarly your first command produces and error code for the same
    reason.
     >
     > Sorry - - - not my policy - - -
     What? Yes, the *system* pip should have some restrictions, if it's a
    system mainly managed by a package manager.
     Setting up a venv is the *expected* approach to such situations, and
    creating one doesn't cause any problems. You end up with a pip in the
    activated venv that's going to install to a different path (the one in
    the venv), and will not be marked as externally managed, as the package
    manager has no control over that path.
     That's the whole point.  What error are you getting?  The venv
    module is
    not the pip module so restrictions on the system pip have nothing to do
    with it.
 set up pyenv
activated a venv
trying to install python3.12 into it
 1. download of python3.12 (blahblahblahetc).deb will not install
2. download of python3.12.tar.xz similarly will not install
 (venv2) memyself@devuanbigbox:~$ pip install /home/memyself/Downloads/Python-3.12.4.tar.xz
Processing ./Downloads/Python-3.12.4.tar.xz
ERROR: file:///home/memyself/Downloads/Python-3.12.4.tar.xz does not appear to be a Python project: neither 'setup.py' nor 'pyproject.toml' found.
 seems that I need a different version (installable as it were) of python3.12
or my approach is all wrong!

you can't install Python "into" a venv.
you use a version of Python as the base when *creating* a venv, the venv will use the same binary as the base python (symlinks if possible, as in the Linux case), but with different paths.
Since you've already got pyenv, use it to build the version you want to use - I think you said there wasn't a deb for 3.12 in your distro? That's something like
pyenv install 3.12.4
that will use the build recipe it has... and hopefully work.  Distro Pythons sometimes have some strange setups that are hard to reproduce. Pyenv knows how to build micropython, too, should it ever come to that.
If you indeed found a deb for the right Python, use apt to install it, and then use *that* Python to create your venv.
If you have the pyenv-virtualenv plugin, you can ask it to make the virtualenv for you, if pyenv built the Python