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> 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/ 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.
--
https://mail.python.org/mailman/listinfo/python-list
