Detection of Django manage.py not predictable. about s2i-python-container HOT 7 CLOSED

i'd almost rather see us just look for it in root and if you want it somewhere else, we give you an env variable to tell us which manage.py file you want to use. how does that sound?

from s2i-python-container.

Rather than environment variable giving path to manage.py in sub directory, my current thinking is that you give it the directory name for the Django project if not in root. The scripts would then look for manage.py within that directory itself rather than user calling it out explicitly. Thus instead of:

DJANGO_MANAGE_SCRIPT=hello/manage.py

would use:

DJANGO_PROJECT_NAME=hello

or similar.

from s2i-python-container.

DJANGO_PROJECT_DIR ?

from s2i-python-container.

To match Django's own name for the directory in settings.py, probably should use DJANGO_BASE_DIR. The settings.py file contains:

# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

where BASE_DIR acts as the anchor point for any configuration to work out where stuff is inside of the project. The calculation should end up being the directory containing the manage.py so matches the directory we want to have be referenced. Thus should use same name stem.

from s2i-python-container.

Rather than making this Django specific, one could generalise it. In that case have generic APP_ROOT where the default currently is effectively /opt/app-root/src. Setting it would mean that all checks would be done relative to the new directory. This way can also apply to checks for app.py and wsgi.py.

I chose APP_ROOT here because other override variables are APP_FILE and APP_MODULE, so carrying through APP_ prefix. Using APP_ROOT may be confusing though when one considers that everything is under /opt/app-root, yet APP_ROOT doesn't actually point to that by default, but the src subdirectory.

As far as overriding APP_ROOT, the simple solution would be that it causes the current working directory to be changed to that directory before anything else is done. The one complication this presents is PYTHONPATH for Python module searches. The /opt/app-root/src directory would be in the module search path due to the fact that command line execution of Python results in special empty string in sys.path, which means look in current working directory. Change the working directory and it will no longer look in /opt/app-root/src so if changing directory because APP_ROOT is set, then should add /opt/app-root/src to PYTHONPATH explicitly. There is actually good argument to add new directory specified by APP_ROOT to PYTHONPATH explicitly as well anyway. This will protect against badly written user code which changes the current working directory itself causing modules then not to be found.

from s2i-python-container.

Alternate name for variable may be APP_HOME. Using HOME in name gives sense that the current working directory or home directory for the application will be changed.

from s2i-python-container.

Depending on where you change working directory may complicate working out name of WSGI module from setup.py as need to be in the top level directory to run setup.py, you cannot run it from within a different directory as not really guaranteed to work. I think I have separately questioned whether is a good idea to use name of module installed by setup.py. Better to make it explicit by requiring use supply a wsgi.py.

from s2i-python-container.