[Distutils] library development patterns

[Joni Orponen]

On Thu, Jan 18, 2018 at 10:13 PM, Chris Jerdonek <chris.jerdonek at gmail.com>
wrote:

> PS - this is the pyenv / tox compatibility issue I had in mind:
> https://github.com/pyenv/pyenv-virtualenv/issues/202
>
> And this I have found is the simplest workaround:
> https://github.com/pyenv/pyenv-virtualenv/issues/202#
> issuecomment-284728205


I find it simpler if you just define multiple pythons in a project specific
.python-version for pyenv as it simply injects them into your path-esque
shim resolving mechanism in order.

The content of one example .python-version of mine:

2.7.14
2.7.14/envs/detox
3.4.7
3.5.4
3.6.4

This way the python2.7 tox finds first is the one from the clean one and
thus creates a clean functional virtualenv from it, likewise for the Python
3 variants.

The detox virtualenv is there so the pyenv provided shim for tox/detox
resolves to that as the first hit. I like for my tox tests to run in
parallel, but this also works for just plain tox (and then you can choose
for which Python version you want to install tox - detox is Python 2.7 only
for now).

The detox virtualenv can be initially created via pyenv virtualenv 2.7.14
detox. Then I usually pyenv shell 2.7.14/envs/detox and pip install detox.
Or this can also be done via a requirements file, if a project pins it for
reproducibility, in which case I'll probably create a project specific
detox/tox virtualenv via pyenv and add that to the project .python-versions
file, thus fully isolating things from each other and having everything
pinned with explicit configuration per project.

And I usually also have a separate 3.6.4/envs/projectname for actually
running the project / for interactive work with the project I enable via
pyenv shell 3.6.4/envs/projectname.

To me this seems the intended way to use pyenv - relying on its core
mechanisms instead of piling up layers of workarounds.

A simpler setup might be:

3.6.4
3.6.4/envs/projectname
3.5.4
3.4.7
2.7.14

But one needs to remember to pyenv shell 3.6.4/envs/projectname in order to
pip install anything to the correct environment as pip3.6 would resolve to
the global one (and one should try to keep that in pristine if trying to do
things this way, even if the point of virtualenv is to isolate you from the
system site-packages). At least the way pyenv modifies the shell prompt
keeps things helpful enough for me to get by, but it is one more layer to
keep track of.

-- 
Joni Orponen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180118/a36ebfd2/attachment.html>