I created a virtual environment using python3.9 -m venv myenv
Now I activate it using source myvenv/bin/activate.
I suppose from this virtual enviroment is some dependency or link created to the installed Python version.
When I uninstall python3.9 can I still launch my python script with this activated virtual enviroment?
no you wont be able to run python applications anymore.
refer https://docs.python.org/3/library/venv.html
venv — Creation of virtual environments¶
New in version 3.3.
Source code: Lib/venv/
The venv module provides support for creating lightweight “virtual environments” with their own site directories, optionally isolated from system site directories. Each virtual environment has its own Python binary (which matches the version of the binary that was used to create this environment) and can have its own independent set of installed Python packages in its site directories.
See PEP 405 for more information about Python virtual environments.
If deleting the installed Python version affects the further use of any virtual environment depends wether option symlinks or copies was used when the virtual environment was created.
From Python docs for module venv, Creating virtual environments:
It also creates a bin (or Scripts on Windows) subdirectory containing a copy/symlink of the Python binary/binaries (as appropriate for the platform or arguments used at environment creation time).
Emphasis mine, to note that the role of the installed Python version depends on options.
The installed Python version is still a dependency, when at the time of creation symlinks have been used. If copies have been used, then the virtual environment is independent of the Python installed version and it can be removed.
See the options:
--symlinks Try to use symlinks rather than copies, when symlinks
are not the default for the platform.
--copies Try to use copies rather than symlinks, even when
symlinks are the default for the platform.
See also: PEP 405: Copies versus symlinks
Related
I am looking into using Tensorflow for my research soon, and looked at the online documentation for installing with Conda https://www.tensorflow.org/versions/r0.11/get_started/os_setup.html#anaconda-installation.
It suggested creating a new environment, and installing Tensorflow in it, and the installing other python packages afterwards.
But I already have an existing environment with lots of packages I need, and I'm wondering if its safe to add Tensorflow into that environment?
Also, I have a question about how this installation with conda works. I know that Conda will create a distinct set of folders containing the libraries needed for each environment, but if I install Tensorflow, what happens to all the base low level C++ and CUDA libraries that get compiled? Do they reside in my Conda environment's folder, or are they in some system wide libraries closer to my root?
PS: I'm using Ubuntu 16.04, and have a GPU that I want to run Tensorflow on.
Thank you.
But I already have an existing environment with lots of packages I need, and I'm wondering if its safe to add Tensorflow into that environment?
conda has this awesome feature called "revisions". You can show your current environment with
conda list --revisions
which allows you to revert changes to your conda environment. This allows you to install new packages with confidence that if something breaks you can always revert it later. See this page for more info: https://www.continuum.io/blog/developer/advanced-features-conda-part-2. tl;dr: conda install --revisions <revision_number>
what happens to all the base low level C++ and CUDA libraries that get compiled
Are you talking about the libraries that get compiled when you are trying to run your code? Or the C++/CUDA libraries? If you're talking about the C++/CUDA libs then conda is not compiling them, but merely installing a pre-compiled binary into a specific location that gets picked up. If you're talking about your code, then where exactly those files live would seem to depend on where you put them.
I am trying to test Debian packages which are built on an x86 Linux system, but which will be executed on an ARM architecture. My {pre,post}{inst,rm} scripts are failing with a "exec format error" because the /bin/bash in the chroot'd environment, which is an image of a flash filesystem, are ARM binaries, not x86 binaries.
What I'm looking for, but cannot find, is an option to dpkg which is like --root, but which doesn't use chroot. I'd presumably need to know the name of some environmental variable (?) which contains the name of the parameter to --root.
It's probably easier to make the /bin/bash (and everything else) in the chroot executable.
Install qemu-user-static on the host. That will give you QEMU user space emulators for all architectures in static versions — so no complications with dynamic libraries in the chroot. It also configures binfmt support to execute ARM binaries with /usr/bin/qemu-arm-static.
Copy /usr/bin/qemu-arm-static into the /usr/bin of the chroot. Now you should be able to chroot and run programs normally. That way your Debian packages can be tested chrooted into their (emulated) native environment.
Alternatively to the good suggestion to use qemu, starting with dpkg 1.18.5 you could use --instdir in conjunction with --force-script-chrootless. Depending on the maintainer scripts you might need to adapt them to make use of the DPKG_ROOT environment variable. There's more information in the dpkg man page.
I'm learning about virtualenv and mod_wsgi and these are my favourite articles so far:
https://code.google.com/p/modwsgi/wiki/VirtualEnvironments
(by the author of mod_wsgi, Graham Dumpleton).
http://www.dabapps.com/blog/introduction-to-pip-and-virtualenv-python/
I understand that virtualenv allows me to have independent instances of Python and Python packages.
But how does this relate to things like Apache, mod_wsgi and MongoDB?
Can these things also be included in this virtual environment?
The scenario I am interested in is being apple to have a local application that is 'self reliant' (that would be easy to install on other systems) - virtualenv seems to enable this to an extent, but can Apache, mod_wsgi and MongoDB only exist at this broader 'system level' or can they exist in a virtual environment?
virtualenv is for python packages only, so you cannot have instances of system applications running within in it, like apache.
Edit: As mentioned by #Graham Dumpleton, it is possible to install apache httpd using mod_wsgi-httpd inside virtualenv. But, as I said earlier virtualenv is for python packages, so it is a matter of finding/writing a package that solves the problem.
That being said, you can make Apache, that uses mod_wsgi, to take advantage of virtualenv. Trick is, configuration has to be done within a python file.
Say you are trying to setup django project myproject, that is running within virtualenv named myproject, here is your wsgi.py:
import os, sys, site
path = os.path.split(os.path.dirname(__file__))[0]
if path not in sys.path:
sys.path.append(path)
site.addsitedir('~/.virtualenvs/myproject/local/lib/python2.7/site-packages')
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
activate_env=os.path.expanduser(
"~/.virtualenvs/myproject/bin/activate_this.py")
execfile(activate_env, dict(__file__=activate_env))
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
Configuration for apache or mongodb wouldn't be any different, since they are system wide running services.
I thought that the standalone PsychoPy install could coexist happily if Python was installed separately on the PC to but I can't get it to, nor can I find any docs. (I'm using Windows 7)
I have the lastest standalone version installed and the shortcut to run it is
"D:\Program Files (x86)\PsychoPy2\pythonw.exe" "D:\Program Files (x86)\PsychoPy2\Lib\site-packages\PsychoPy-1.81.02-py2.7.egg\psychopy\app\psychopyApp.py"
This works fine if my system env variables for PYTHONHOME & PYTHONPATH aren't set but I also use Python for other apps and need them setting to point to the other version of Python I have installed natively. When these env vars are set, Psychopy fails to load and gives no error messages at all.
Can anyone advise how I get them to play together nicely? (I thought it used to work last year, has something changed?)
[ I've tried a full uninstall of psychopy and freshly installed the latest standalone version v1.81.02
Yes, this is an unfortunate consequence of the way that PsychoPy is currently bundled with it's own closed environment in it's own python and dependencies installed seperately.
However, a new option to install psychopy using the conda package manager was introduced recently for Mac OS but some have also got it to work on Windows with a bit of tweaking.. Work is currently ongoing for this feature. I doubt that it was working previously unless you manually installed all dependencies in your default python, or ran linux:
On linux you can simply install psychopy from the neuro.debian repository, making it available for python system-wide. See PsychoPy documentation.
Thinking about it, I don't think it would ever worked if you had set PYTHONPATH (I don't know about PYTHONHOME).
BUT I did have a 'regular' python installation running alongside my Standalone PsychoPy install by not using the PYTHONPATH variable. You can add further paths to your python importing path (I assume that's the aim here) without setting any environment variable by adding text files ending in .pth to your site-packages directory. Essentially any lines in a .pth file that is found while navigating the existing path will also be added to the path!
Actually, according to the python docs you can also set a flag -E to ignore the environment variables:
https://docs.python.org/2/using/cmdline.html
To use that solution for the Standalone PsychoPy installation you'd have to alter the application shortcut to add this (that should get the app to load), but also make a couple of changes to the code for running scripts so that they also run with the flag set.
I still think not setting those variables is the easier solution though.
cheers,
Jon
Just wondering if it's possible and what the best route might be to run a full-on Linux distro within my existing distro? It would be great to for instance run Arch Linux within a chroot, jail, etc.. I believe people are doing this on Chromium for example.
I would require that whatever fs loaded, I can install packages using pacman and that my changes are kept intact.
I have tried the Virtualbox route by the way and there is a pretty nasty bug involving double mouse pointers on rotated host screens that I can't seem to get around.
I should mention that I'll be using this chroot environment for development, maybe running the odd X client to be exported remotely, etc..
I followed the chroot guide at https://wiki.archlinux.org/index.php/Change_Root and basically installed a whole Arch system within a nested chroot according to the Arch Linux installation guide and I'm now able to switch to the environment at will.
There is a tool https://github.com/fsquillace/junest that does everything automatically for you (downloads and unpacks ArchLinux distro inside some folder and chroots there).