- The last part of the module import path is the module name. This also
becomes the Django app name. Apps names have to be unique. Hence,
there is no scope for two different modules with same name but
different load path to exist in the project.
- Most uses of list of loaded modules are dealing with app names instead
of full module load path. This is due to the fact that Django deals
with app names and not module paths.
- It is also somewhat clumsy to access a loaded module as we are
re-importing every time to get access module.
- Simplify all of the above by using app names are module identifiers
and maintaing an ordered dictionary of app names to loadded modules.
- Remove unused imports.
- Minor styling fixes.
Earlier, installation of the ownCloud package was performed as part of
setup process. It took time and hence the action was done
asynchronously. Now, however, package manager takes care of this. To
avoid any potential race conditions with the user accessing ownCloud
before it is setup, perform the setup synchronously.
- For each application, add ./tests directory and __init__.py file
within it.
- Modify test controllers (coverage.py, runtests.py) to find the new
test directories for testing and coverage analysis.
- Move existing application-specific test modules (test_pagekite.py) to
the newly created directories.
- Don't allow strings to be sent as arguments. The mixup with
lists/tuples could be dangerous.
- Don't escape arguments. subprocess.Popen takes care that arguments
are passed on nicely to the actions.
- Update tests.
The package license (AGPL3+) implicitly indicates the license of each
file. However, it is desirable to have license headers in each file.
This is the case for many prominent projects like GNU project, Mozilla
etc.