Right now creating a virtualenv with a custom version of Python is harder than it needs to be: check if you have it installed, if now find the proper way to install it for your OS, then proceed to choose between the exe/conda/ppa/deb/homebrew solution according to your need and the specific version you want, then install and create the virtualenv with the proper command.
pythonz allow you to easily install any Python version. Including legacy ones (2.6) and brand new ones (3.6). pew already integrates it. It would be great to be able to do:
pipenv install foo --python 3.6
And be done with it. It just check if Python 3.6 exists on my machine, and if not, use Pythonz to provide it in my env.
I am open to this, but currently the design only requires that you have python2
and python3
installed on your machine, which every Python developer should have anyway.
I would advocate the opposite of this. Pipenv
, to me, draws from Ruby's Bundler project which is different from Pythonz
, Pyenv
, etc. which are inspired by Ruby's Rbenv
(RVM
, Node's NVM
, Nix
, etc. etc. etc.).
I haven't checked yet, but I would suggest that the goal should be to only: "Play nicely with Pythonz, Pyenv, etc."
Pipenv
works fine with pyenv
as far as I tested (py3
). Should be straightforward to test with pypy
etc.
I'd just like the option to specify the _specific_ Python interpreter I want. For example, I also use pythonz
because I still have some (work) projects that require Python 2.6. I'd like the option to do something like pipenv -p ~/${HOME}/.pythonz/pythons/CPython-2.6.6/bin/python2.6
when creating a virtual environment.
I think just 2/3 is good enough for 90% of users.
Your project; your decision. I guess I'm in the 10%. 馃槅
Ideally it should be as easy as specifying the minimum (or maximum) required version of python (with semver) in your Pipfile
. pipenv
should take care of the rest.
For example, a python2 config might look like this:
[system] # where only 1 of [ "cpython", "pypy2.7", "pypy3.3", "jython"... ] is allowed
cpython = "^2.7"
currently, requires is intended for app deployments, e.g. targeting specific versions, not version ranges.
Does this mean that pipenv should play nicely with conda?
Most helpful comment
I would advocate the opposite of this.
Pipenv
, to me, draws from Ruby's Bundler project which is different fromPythonz
,Pyenv
, etc. which are inspired by Ruby'sRbenv
(RVM
, Node'sNVM
,Nix
, etc. etc. etc.).I haven't checked yet, but I would suggest that the goal should be to only: "Play nicely with Pythonz, Pyenv, etc."