Multiple python versions, one dev environment???

[Joep van Delft]

Hello Javier! 

Thanks, those links are helping a bit. And: yes, I am using Archlinux.

But still those links assume that there are totally separate
site-packages* directories installed for both. I am not sure how I
would surpass this distinction between py-X.P and py-Y.Q. 

Should I really create a massive amount of symlinks like this?: 

| #!/usr/bin/zsh
| for d in ~/src/mypackage/**/*(/); do 
|    # matches all directories
|    mkdir -p "~/src/py-2.7/mypackage/${d#*src/mypackage}"
|    mkdir -p "~/src/py-3.4/mypackage/${d#*src/mypackage}"
| done
| for f in ~/src/mypackage/**/^*.pyc(.); do 
|    # matches all files except for *.pyc
|    ln -s "$f" "~/src/py-2.7/mypackage${f#*src/mypackage}"
|    ln -s "$f" "~/src/py-3.4/mypackage${f#*src/mypackage}"
| done

...and then set $PYTHONPATH according to the target version in a
#!/usr/local/bin-script? 

I can work with this (have not tried though), but there must be a
more elegant solution than symlinking my way forward... 

Cheers!


    Joep



On Thu, 17 Jul 2014 16:05:27 +0000 (UTC)
Javier <nospam at nospam.com> wrote:

> Are you using arch linux.  
> 
> 
> I deal with multiple interpreters putting fake executables in
> /usr/local/bin for everything: (python, sphinx, virtualenv, pydoc,
> idle, python-config...) selecting 2 or 3.  You can do the same for
> selecting 2.3, 2.5, 2.7.  What the scripts do is to detect whether
> it is a system script whose prefix starts with /usr/bin, or whether
> it is a user script.  Being in /usr/local/bin they will override
> executables in /usr/bin. Remember to chmod a+x the files
> in /usr/local/bin
> 
> http://sindhus.bitbucket.org/manage-python-2-3.html
> http://stackoverflow.com/questions/15400985/how-to-completely-replace-python-3-with-python-2-in-arch-linux
> https://wiki.archlinux.org/index.php/Python#Dealing_with_version_problem_in_build_scripts
> 
> I use these scripts, but there is more than one way to do it
> 
> ========/usr/local/bin/python===========================================
> #!/bin/bash
> script=`readlink -f -- "$1"`
> case "$script" in
> /usr/bin*)
>     exec python3 "$@"
>     ;;
> esac
> exec python2 "$@"
> 
> ========/usr/local/bin/virtualenv===========================================
> #!/bin/bash
> script=`readlink -f -- "$1"`
> case "$script" in
> /usr/bin*)
>     exec virtualenv3 "$@"
>     ;;
> esac
> 
> exec virtualenv2 "$@"
> 
> 
> 
> 
> 
> 
> 
> 
> Joep van Delft <joepvandelft at xs4all.nl> wrote:
> > Hello! 
> > 
> > The condensed version of the question would probably be: How does
> > one deal with multiple interpreters and one package where you
> > want to try some changes? 
> > 
> > The background: 
> > I made a trivial change to some package (docutils) to scratch a
> > personal itch, and I want to offer this back to the community
> > (whether it will be accepted or not). Because of this, I ran into
> > some issues. 
> > 
> > Some facts:
> > 1. Python3 is my main interpreter. 
> > 2. The tests of docutils only run under python2.
> > 3. I desire not to touch my distribution's version of
> >   site-packagesX-Y.
> > 4. I prefer to have one and only one development directory of
> >   my target package. 
> > 
> > My confusions: 
> > 1. Is it possible to have one source control managed directory of
> >   some package, which is used by two versions of python? 
> > 2. I assume that the *.pyc-files generated while using some python
> >   source are version dependent. What is the recommended way to
> > have 'em both installed? 
> > 3. The way I have stumped a wall over here, is the puzzle of how
> > to make python2 have a different $PYTHONPATH as python3. I hope to
> >   hear how this strategy is silly :) 
> > 4. I have contemplated the way of linking the source files from my
> >   development directory into user specified site-packages
> >   directories. Problem 3. still is valid. 
> > 5. Should venv and friends/foes com into play? If so: How? 
> > 
> > Appreciate any light shed on these issues. 
> > 
> > Thanks! 
> > 
> > 
> >        Joep
> > 
> > 
> >