We Keep Coding

Django, how to run a command through Windows Task Scheduler

How to schedule and run a specific command in django using Windows Task Scheduler. My django project is not currently local server deployed but using the manual set up just like activating the virtual environment and then typing the python manage.py runserver on terminal rather deploying through xampp or laragon. But i am bit confused on how to achieve to schedule and run a command like python manage py get_source through the use of Windows Task Scheduler.

Don't know if you're still looking for this but I found a working solution here - configure .bat file to run commands in Django Virtual Env
Very simple; point to the location of your project directory...
cd C:\webapps\my-project-dir-with-manage.py-inside
copy and paste the contents of the system generated activate.bat,found inside your venv/Scripts folder...
add your command line...
.\manage.py <your command here>
save as myfile.bat, and schedule via the Windows Task Scheduler.
Super simple.

I had the same problem.
The main issue is, that you missed the full path to python.exe as an execution application. "Python" will not work.
And then your application as an argument.
Additionally, to that, you can add w to py. This will make it runnable on windows without a .bat file.
Application to execute:
C:\user\python.exe Argument: manage.pyw runserver

How to debug remote python script?

I am looking for a way to debug remote python script without any set up like in the answer here
I set remote interpreter, set up a debug configuration, click a debug button and got error Event not found:
ssh://myuser#my_ip:my_port/usr/local/bin/python -u /myuser/.pycharm_helpers/pydev/pydevd.py --multiproc --qt-support --client '0.0.0.0' --port 46994 --file /opt/my_work_dir/my_script.py
/: Event not found.
Seems like pyCharm takes care about all debug setting --multiproc --qt-support --client '0.0.0.0' --port 46994 but I have the wrong configuration.
Is there a way how to debug python script without putting pydevd.settrace('host', port=21000, stdoutToServer=True, stderrToServer=True) and other actions?

I was able to fix this problem by reinstalling PyCharm.
(# 1 and 5 are optional)
Export minimum settings you want to restore such as Keymap (File > Export Settings)
Uninstall your current PyCharm
Install new PyCharm
Launch new PyCharm and don't import your pre-existing setting at the first start up
Import your settings from the old PyCharm (File > Import Settings)
I guess this happens when some environment related settings are messed up.
Notice that you need to remember your settings for the remote interpreter as it will be gone when reinstalling.

I use vagrant quite often with pycharm and debugging has always worked great for me as long as i setup the interpreter to the one inside the vagrant box running.
If you go to settings->project->project interpreter and then setup a connection to your remote interpreter it will usually install the pycharm-debug.egg etc and you can debug run your project against this interpreter and set breakpoints in pycharm and it will break on those.
Here is their docs on setting this up https://www.jetbrains.com/help/pycharm/2016.1/configuring-remote-python-interpreters.html

I set up remote debugging as described under the section
Remote debug with a remote interpreter
(not the Server!!) and it works very well.
Here the link: https://www.jetbrains.com/help/pycharm/2016.1/remote-debugging.html
You just have to set up the remote interpreter (I used ssh) and then set up your run configurations. Let me know if you need further help.
Here is my run configuration in PyCharm:

It might be the same issue as this. Use bash as your login shell if you use another one like csh or tcsh.

How to make sudo execute in current python virtual environment?

I have a django website setup and configured in a python virtual environment (venv) on Ubuntu and all is working fine. Now in order to to run my server on port80 I need to use "sudo" which does not execute in the context of the virtual environment, raising errors (i.e no module named django ...)
Is there a way to get "sudo" to execute in the context of the python virtual environment?!

No, you don't need to do this. You shouldn't be trying to run the development server on port 80; if you're setting up a production environment, use a proper server.

As #DanielRoseman said you should not be using the Django development server in production.
But if you need to run the development server on port 80 you have to reference the use the virtual environment python executable directly.
sudo ../bin/python manage.py runserver localhost:80

This should be the solution.
Even tho I really don't recomment doing this. If you need sudo within Python you are probably on a wrong way.

this did the trick:
$ sudo -- sh -c './venv-bin-path/activate; gunicorn <params> -b 0.0.0.0:80'

uWSGI flask.ini uses global Python or virtualevn Python?

This following codes are inside a uWSGI configuration file called flask1.ini:
[uwsgi]
socket = /tmp/flask1.sock
chmod-socket = 777
evn = PRODUCTION=TRUE
module = indy
callable = app
processes = 4
threads = 2
logto = /var/indylog
The production server is set up on ubuntu 14.04 using uWSGI and nginx for Flask application.
I wrote a new module that uses Python 2.7 and it runs without any error on my local ubuntu 14.04 virtualenv (Flask development server) and the same nginx and uWSGI set up as the production environment. However, when I deployed the same code live on production server, it gives a bunch of syntax errors, I am trying to figure out why this is the case.
I run python --version on my local desktop and production server, they are both Python 2.7.6.
My questions: with the above uWSGI configuration on production server, which Python is being used? The machine Python or virtualenv Python?

To be precise, neither. uwsgi does not actually run the Python binary, it uses libpython directly. It just follows your system's LD_LIBRARY_PATH to find the corresponding libpython library and this is normally not affected by virtualenv.
What is affected by virtualenv, however, is the location from which uwsgi will load your packages. You will still need to add a line in your uwsgi.ini to specify the path your virtualenv like this:
virtualenv = /path/to/your/virtualenv
If you wish to configure uwsgi to use different versions of libpython, you will need to build the corresponding plugin for each version and specify it in uwsgi.ini. You can find more information about this here

At first, you have to create Python 3 environment for your source code:
virtualenv -p /usr/bin/python3 path_to_your_project/env
And install packets required:
cd path_to_your_project
source env/bin/activate
# you can use pip to install packets required, e.g:
pip install -r requirements.txt
Finally, add virtualenv to your uwsgi.ini file:
virtualenv = path_to_your_project/env

Install uwsgi in the virtualenv to use whichever Python version the env is configured with. /path/to/env/bin/uwsgi --ini /path/to/flask.ini. Instead of global uwsgi path/to/your/flask.ini, which would use the Python version that the system installed.

Openshift 2.1 cannot set OPENSHIFT_PYTHON_WSGI_APPLICATION using action hooks

I am trying to deploy a Django app on openshift (python3.3, django1.7, Openshift 2.1).
I need to set the OPENSHIFT_PYTHON_WSGI_APPLICATION to point to an alternative wsgi.py location.
I have tried using the pre_build script to set the variable, using the following commands:
export OPENSHIFT_PYTHON_WSGI_APPLICATION="$OPENSHIFT_REPO_DIR"geartest4/wsgi.py
echo "-------> $OPENSHIFT_PYTHON_WSGI_APPLICATION"
I can see during the git push that the pre_build script sets the variable correctly. The echo shows the correct path as expected. However wsgi.py does not launch and I get:
CLIENT_ERROR: WSGI application was not found
When I immediately ssh into the gear and check the environment variable I see that OPENSHIFT_PYTHON_WSGI_APPLICATION="" is not set.
If I set the variable manually from my workstation using rhc set-env OPENSHIFT_PYTHON_WSGI_APPLICATION=/var/lib/openshift/gear_name/bla/bla then the variable sticks, the wsgi server launches, and the app works fine.
The problem is that I don't want to use rhc set-env because that means I have to hardwire the gear name in the path. This becomes a problem when I want to do scaling with multiple gears.
Anyone have any ideas on how to set the variable and make stick?

The environment variable OPENSHIFT_PYTHON_WSGI_APPLICATION can be set to a relative path like this:
rhc env set OPENSHIFT_PYTHON_WSGI_APPLICATION=wsgi/wsgi.py
The openshift cartridge openshift-django17 by jfmatth uses this approach, too.