Creating virtualenv with virtualenvwrapper - virtualenv

I have a very simple question. According to this snippet, I have created a virtualenv named newConda in this address C:\Users\....\Envs. So, my question is: how can I create this virtualenv in any other path of my choice, for example, in E:\programming\New folder?

One of the advantages of virtualenvwrapper is that it stores all your virtual environments in one place so it can manage them at once.
If you want to create a virtual environment in another place you just use virtualenv instead of virtualenvwrapper.
If you want to store all your virtualenvwrapper's virtual environments in a different directory define (change) environment variable WORKON_HOME:
set WORKON_HOME=E:\programming\New

Related

Setting the MODULE_PATH variable for default env of spack

Lately, the mechanism used by Spack to manage the modules (I refer to the Environment Modules and to LMod) changed a little bit to allow a better integration with the spack environments (see pull request #23703).
Unfortunately, this also affect the fact that Spack does not update anymore the MODULE_PATH variable by default; indeed, the documentation still reports that
If you have installed a supported module system you should be able to run either module avail or use -l spack to see what module files have been installed.
but, at least on my machine, after installing a few packages, the module avail command does not show any new module (I am using commit 9936182). I suppose that this happens because now Spack want to know which environment should be loaded.
Of course,the problem could be easily fixed by adding the directory with the modules in the MODULE_PATH env var, but I am not sure that this is the best practice.
Is there a way to say to spack: "please, load the modules of the default environment?"
Thank you

Vagrant Berkshelf - Shelf Path?

Is it possible to set the path where the berkshelf plugin puts the cookbooks it installs? (As in the .berkshelf folder)
I am running Windows 7.
I am currently trying to install a mysql server using an opscode cookbook to a vm and here at work they have the %HOMEDRIVE% system variable set to a network drive. So when .berkshelf starts at the beginning of the Vagrantfile, it pushes the cookbooks to the network drive and it causes it to be slow and well, its not where it should be. Is there a fix to this?
VirtualBox did this as well, but I fixed it by altering the settings. I tried looking for some sort of equivalent settings for berkshelf, but the closest I got was for the standard berkshelf (thats not a vagrant plugin), it appears you can set this environment variable:
ENV['BERKSHELF_PATH']
Found here:
http://www.rubydoc.info/github/RiotGames/berkshelf/Berkshelf#berkshelf_path-class_method
I need to be able to have the cookbooks it reads from the berksfile store to my laptops local drive instead, as in my scenario I cannot have the mobility of the VM limited to the building because of files that are stored on the network.
Any incite would be much appreciated.
Perhaps its better to use the actual berkshelf over the vagrant plugin?
Thanks.
If you want to have the portability - a full chef-repo ready for chef-solo runs, better off using standalone berkshelf instead of the vagrant-berkshelf plugin - which is NOT that flexibly.
For complex cookbooks, I prefer to use standalone berkshelf as it allows me to do berks install --path chef/cookbooks to copy all cookbooks required from ~/.berkshelf/cookbooks, then I can just tar the whole thing and transfer to other machines for the same chef-solo run. some people use capistrano automate the tar and scp/rsync over the network. I just use rysnc/scp;-)
HTH

What does "source" create or activate the virtual env?

I'm brand new to python, using terminal, pip and virtual env.
From what I gather, the command 'source' activates the virtual environment and anything you do after that stays in the virtual environment like installing something with pip installs it only in your virtual environment. However, do I need to actually create a folder or choose a location first before I run source? In other words, does source create the virtual environment or only activate one that already exists?
This stuff is really hard to wrap my head around. I think one of the things that is hindering my development is that I'm not familiar with certain directory structures like bin, ect.
Once you create a virtualenv, you will see source created in the directory.
You must cd to that particular source and do source activate to start working on that particular virtualenv. Each virtualenv has its own source.
You can also use virtualenv wrapper to make things easier.
Look, you need to create the virtual enviroment first, with something like this:
virtualenv venv
Where 'venv' is the destination directory. After that you can run:
source venv/bin/activate
You can take a look at virtualenv help with:
virtualenv --help

share settings between multiple machines by source control system

I have multiple linux machine. I want to share my .vimrc, .hgrc. But, there are a little difference between different machines. Is there smart method?
I'm using mercurial.
mkdir settings
ln ~/.vimrc settings/vimrc
ln ~/.hgrc settings/hgrc
then use mercurial to keep settings.
There are a little difference of hgrc file on different machine.
I require to branch merge always.
I'm wonder is there better method?
What I typically do is have a .bashrc, etc. file that is common on all systems, and then I source a local version called .bashrc.local or something like that, that doesn't get saved in source control with the machine specific settings.
In .bashrc:
. ~/.bashrc.local
In .vimrc
:source ~/.vimrc.local
etc.
If you want to get fancy you can store your local settings files in source control by using your hostname as a discriminator on the local file name. So instead of .vimrc.local you could do .vimrc.machine1.local, etc.
There is another (overkill ?) technique that may complement other answers.
I use puppet which is a tool for automatically configuring machines. I write my puppet config (stored in version control) then deploy it on the target machines. It offers a "template" feature which works for any file.
For example, you write a .vimrc.erb file like that :
ENV_VAR=<%= varvalue %>
with "varvalue" depending on the target machine. With correct puppet declarations ("for machine xyz, put a .vimrc file in home generated from template .vimrc.erb with varvalue=xyz") you then deploy the config to the target machine.
It uses the powerful "embedded ruby" templating mechanism, so you can even write some ruby code to generate the values. You may want to use it directly without puppet : erb

XEN How to put virtual machines in a directory other than /etc/xen

On my CentOS 5.2 box the XEN virtual machine configuration files have to be located
in /etc/xen to be started without specifying a path.
I want to move my virtual machines into /etc/xen/vm to separate them from the
configuration files of the xen server.
Is there an easy way to change the default directory from /etc/xen to /etc/xen/vm ?
The easiest way to do it is to follow this tutorial, use xen-tools to generate VMs for you, and specify where you want to put your VMs. You can then just modify a config file in there (xen-tools.conf) and change the dir property:
dir = /etc/xen/vm
There's a little extra work involved since you're on CentOS (and it's a lot easier if you're on Ubuntu), but it's still do-able.