From 495d0ad337c0ada26dc01ccc8f2a55a7d04a2a12 Mon Sep 17 00:00:00 2001 From: Guido Günther Date: Sun, 8 Feb 2015 14:33:26 +0100 Subject: Details on virtualenv and bundler --- development/non_root.mdwn | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) (limited to 'development') diff --git a/development/non_root.mdwn b/development/non_root.mdwn index 680d7ee..755382d 100644 --- a/development/non_root.mdwn +++ b/development/non_root.mdwn @@ -17,7 +17,7 @@ While this is o.k. if you know what you're doing and you give a crap about package management risking to break other scripts and tools by introducint new library versions it is often much better to not install the libraries into a location where other tools can setp on it -(e.g. /usr/lib, /usr/bin or /usr/local/*). +(e.g. /usr/lib, /usr/bin or /usr/local/\*). ## Ruby @@ -39,7 +39,13 @@ With that in place you can run bundle install --path=vendor and it will fetch the gems and put them into vendor/. No cluttering of -any directories outside your project. +any directories outside your project. You can run commands from that via + + bundle exec + +e.g. + + bundle exec rake spec ## NodeJS @@ -58,4 +64,18 @@ For a limited set of libs you can do: make install export LD_LIBRARY_PATH=$PREFIX -see e.g. liblanfahr's ./run +see e.g. libplanfahr's ./run + +## Python + +For Python there's virtualenv + + virtualenv newtestenv + source newtestenv/bin/activate + +From there on you can use the new environment already, e.g. install a module into it: + + cd mymodule + python setup.py install + +This would install the module (along with it's dependenies) into you new *testenv*. -- cgit v1.2.3