Hello, I'm currently activating my Flask app's virtualenv and starting my server(s) via a Bash script, but I'd like to be able to do it from Python so that I can include it directly in a Fabric function or Flask-Script script. Is there a way to do this? I've tried the method described for use with mod_wsgi (using execfile() on activate_this.py) but without success. (I'm actually using gunicorn + nginx but thought I may be able to adapt the technique). What's best practice for this situation? Thanks - John
On Thu, Jan 5, 2012 at 9:29 AM, John Mastro <john.b.mastro@gmail.com> wrote: > Hello, > > I'm currently activating my Flask app's virtualenv and starting my > server(s) via a Bash script, but I'd like to be able to do it from > Python so that I can include it directly in a Fabric function or > Flask-Script script. Is there a way to do this? > > I've tried the method described for use with mod_wsgi (using > execfile() on activate_this.py) but without success. (I'm actually > using gunicorn + nginx but thought I may be able to adapt the > technique). > > What's best practice for this situation? I always use explicit path to the bins inside the virtualenv (e.g. bin/python), never relying on the behavior of "activate". For example, if you are running a script from the command line, you can set the shebang line to the bin/python of the virtualenv, e.g.: #!/home/appuser/appenv/bin/python Or when I set up cron job: * * * * * /home/appuser/appenv/bin/python /home/appuser/appenv/app/some_script.py Or when I'm managing a daemon (e.g. the app server) from supervisord: command=/home/appuser/appenv/bin/gunicorn -w4 app:app -steve
Thanks Steve. Python's path for modules will be set correctly using this method? I'm using --no-site-packages. For anybody else looking for similar functionality, another good option (which I of course found immediately after asking) seems to be Fabric's prefix contextmanager. You can cleanly prefix a block of commands with your "workon" command or a call to a specific Python bin. - John On Jan 5, 2012, at 9:57 AM, Steven Kryskalla <skryskalla@gmail.com> wrote: > On Thu, Jan 5, 2012 at 9:29 AM, John Mastro <john.b.mastro@gmail.com> wrote: >> Hello, >> >> I'm currently activating my Flask app's virtualenv and starting my >> server(s) via a Bash script, but I'd like to be able to do it from >> Python so that I can include it directly in a Fabric function or >> Flask-Script script. Is there a way to do this? >> >> I've tried the method described for use with mod_wsgi (using >> execfile() on activate_this.py) but without success. (I'm actually >> using gunicorn + nginx but thought I may be able to adapt the >> technique). >> >> What's best practice for this situation? > > I always use explicit path to the bins inside the virtualenv (e.g. > bin/python), never relying on the behavior of "activate". > > For example, if you are running a script from the command line, you > can set the shebang line to the bin/python of the virtualenv, e.g.: > > #!/home/appuser/appenv/bin/python > > Or when I set up cron job: > > * * * * * /home/appuser/appenv/bin/python > /home/appuser/appenv/app/some_script.py > > Or when I'm managing a daemon (e.g. the app server) from supervisord: > > command=/home/appuser/appenv/bin/gunicorn -w4 app:app > > -steve
On Thu, Jan 5, 2012 at 10:01 AM, John Mastro <john.b.mastro@gmail.com> wrote: > Thanks Steve. Python's path for modules will be set correctly using > this method? I'm using --no-site-packages. Yes! That is how virtualenv works, see here: http://www.virtualenv.org/en/latest/index.html#what-it-does "This creates ENV/lib/pythonX.X/site-packages, where any libraries you install will go. It also creates ENV/bin/python, which is a Python interpreter that uses this environment. Anytime you use that interpreter (including when a script has #!/path/to/ENV/bin/python in it) the libraries in that environment will be used." > For anybody else looking for similar functionality, another good > option (which I of course found immediately after asking) seems to be > Fabric's prefix contextmanager. You can cleanly prefix a block of > commands with your "workon" command or a call to a specific Python > bin. That should work as well, but I consider activate and virtualenvwrapper to be conveniences for development. For actual deployment, I always use the explicit paths. -steve
Hi If all the above mentioned doesn't work add virtual env path .wsgi file like or index.py depending on your hosting. Here: My actual application lies in * /home/kracekumar/webapps/test_gummi/htdocs/Gummi* My virtual env name is * env.* and path for virtual env is * /home/kracekumar/webapps/test_gummi/htdocs/Gummi/env* sys.path = ['/home/kracekumar/lib/python2.7/virtualenv-1.6.4-py2.7.egg', '/home/kracekumar/lib/python2.7', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi/env/ lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi/env/ lib/python2.7/site-packages/pip-1.0.2-py2.7.egg', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi/env/lib/python27.zip', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi/env/lib/python2.7', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi/env/ lib/python2.7/plat-linux2', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi/env/ lib/python2.7/lib-tk', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi/env/ lib/python2.7/lib-old', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi/env/ lib/python2.7/lib-dynload', '/usr/local/lib/python2.7', '/usr/local/lib/python2.7/plat-linux2', '/usr/local/lib/python2.7/lib-tk', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi/env/ lib/python2.7/site-packages', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi', '/home/kracekumar/webapps/test_gummi/htdocs/Gummi/gummi',] + sys.path -- * Thanks & Regards "Talk is cheap, show me the code" -- Linus Torvalds kracekumar www.kracekumar.com *