Allow specifying arbitrary Python versions/executables
See original GitHub issueE. g. with the -p/--python
flag like one we have in Virtualenv:
pipenv -p python3.6
Right now it can be done by manually creating a .venv
before using pipenv:
virtualenv -p python3.6 .venv
pipenv
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:9 (6 by maintainers)
Top Results From Across the Web
3. Configure Python — Python 3.11.1 documentation
New in version 3.11. --enable-pystats¶. Turn on internal statistics gathering. The statistics will be dumped to a arbitrary (probably unique) file in ...
Read more >No method to control the python version used #522 - GitHub
To me, the ideal thing would be to a way to get arbitrary versions of python, like tox, and allow it to be...
Read more >Arbitrary Python versions on Flip - edunham
Arbitrary Python versions on Flip. A question in the #osu-lug channel about running python 2.7 on a school server (which only has python...
Read more >3. Using Python on Windows — Python 3.6.3 documentation
The Python launcher for Windows is a utility which aids in locating and executing of different Python versions. It allows scripts (or the...
Read more >Debug arbitrary executables | CLion Documentation - JetBrains
You can use CLion to debug an executable that was built elsewhere using any build ... Setting a custom executable in the CMake...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@iamale I highly recommend using pyenv to manage and select between multiple versions of Python.
Mucking around with the default system-wide python version is a good way to break random distro stuff though, even if it’s only mucked up for the current user. In #python at least, we strongly discourage people from doing that just due to the random breakage of unrelated things it can cause.
A somewhat related note, it’d be really handy to be able to have multiple venvs for a project, for different python interpreters; there isn’t always a CI tool involved, and a lot of the benefits of pipenv seem to disappear once you start trying to work with multiple interpreters.