One possible solution is to use RP's suggestion to leverage the --user argument (which stores packges in $HOME/.local/lib/python3.4/site-packages.
>pip3 install --user -r poky/bitbake/toaster-requirements.txt * works except wsgiref is not python3 compatible yet >pip3 list installed --local argparse (1.2.1) beautifulsoup4 (4.4.1) Django (1.8.13) * works to show what is a --user install vs a global site install. > pip3 uninstall/install --user --upgrade/.... works as expected... -b On Tue, May 31, 2016 at 11:28 AM, Brian Avery <[email protected]> wrote: > So, > From my admittedly brief web searches, I found multiple online > references to the fact that, by design, both virtualenv and venv are > designed to 'jail' a particular python version as the default. > Unfortunately, this means there aren't any arguments that allow either > of these approaches to simultaneously support both python2&3. > > A hack: > if you really want to maintain both versions with the convention that > python will invoke python2 and python3 will invoke python3 then you > can do: > ------------- > python3 -m venv python3_venv > rm python3_venv/bin/python > . ./python3_venv/bin/activate > ------------- > > This results in python resolving to the host version, typically, > /usr/bin/python aka python2. python3 will resolve to > python3_venv/bin/python3. pip will resolve to the python3 pip. Since > we will need to have modules installed for python3 for toaster, this > is what we want. I tried some pip installs of both compiled modules > and pure python modules and these were correctly installed as python3 > modules. > In this environment if you want to install a python2 modules, pip2 > install <foo> will do that. > > Since I don't know what side effects this might have, suggesting this > as a "solution" seems silly. However, I wanted to put this out there > since it did work for me in case someone is stuck... > > Unfortunately, this doesn't really solve what we do for toaster... > > -bavery > > > > > On Tue, May 31, 2016 at 7:09 AM, Christopher Larson <[email protected]> > wrote: >> >> >> On Tue, May 31, 2016 at 3:45 AM, Richard Purdie >> <[email protected]> wrote: >>> >>> The move to python3 is unsurprisingly causing some issues in places. >>> One of them is unfortunately the use of vritualenv, which as I >>> understand it, toaster currently promotes as its preferred way of being >>> run. >>> >>> The issue is that we need "python" to be python v2 but "python3" to be >>> python v3. It seems with virtualenv you can either have python v2 or >>> python v3 but not both. >>> >>> The python developers official party line is that "python" is v2 and >>> "python3" is v3. There are some distros choosing not to do this (e.g. >>> Arch Linux) but most are following the official recommendation and I >>> think OE needs to follow the official recommendation too. Its likely OE >>> will need to error with sanity test failures if the environment doesn't >>> conform to this view of the world. >>> >>> Why do we need this? We have a mixture of code, some of it is ported to >>> v3, some isn't. Whilst we're aiming to convert all of "our" code to >>> python v3, even once we've done that, we can't easily change scripts >>> that ship with the source code we build for example, or expect everyone >>> to do that for all software they build. >>> >>> It may be virtualenv can be configured to not take over "python" but >>> only "python3" but Ed/I haven't found the option, I'm no expert. >>> >>> The other alternative is to promote the use of something like "pip3 >>> install 'Django>1.8,<1.9' --user" instead. Toaster doesn't need many >>> modules and those it does need should be installable into the user's >>> homedir using pip3. >>> >>> Whilst this means changing the documentation and taking a new approach, >>> I think its the "least bad" solution we have right now. >>> >>> Obviously I'm open to other ideas but we really do need a way which >>> allows mixed versions of python and virtualenv doesn't seem to work for >>> this. >> >> >> virtualenv is the wrong tool to use for python 3. python 3 includes its own >> tool for managing virtual environments, pyvenv. See >> https://docs.python.org/dev/library/venv.html. >> >> As an FYI, you can run either virtualenv or pyvenv for an arbitrary python >> version by running it with python -m virtualenv or python -m venv, and >> virtualenv takes a -p argument to specify the path to the python executable. >> But of course that doesn't matter, since we don't need to use virtualenv in >> python 3 environments. But still, useful to know that both python packages >> provide an __main__. >> -- >> Christopher Larson >> clarson at kergoth dot com >> Founder - BitBake, OpenEmbedded, OpenZaurus >> Maintainer - Tslib >> Senior Software Engineer, Mentor Graphics >> >> -- >> _______________________________________________ >> toaster mailing list >> [email protected] >> https://lists.yoctoproject.org/listinfo/toaster >> -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
