It is no longer very useful and floods the log window, taking our attention away
from more import things. It is only useful during new module development. Module
load order message helps anyway.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
This introduces flake8 and fixes a bunch of flake8 errors.
flake8 is run with: ./venv/bin/flake8 plinth
if you're using a python3 venv.
We can eventually further integrate this with gitlab ci.
https://salsa.debian.org/freedombox-team/plinth/issues/58
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Instead of the need to run './setup install' to install the module-enabled files
into /etc/plinth/modules-enabled, pickup module configuration from app/data
directories in development mode.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
User will be shown captcha in the second attempt to login if login
fails in the first attempt.
Signed-off-by: Joseph Nuthalpati <njoseph@thoughtworks.com>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Use simple_tag() instead of assignment_tag(). Assignments with simple_tag()
works just like before.
- When loading urls for application, specify application name during inclusion.
- Use the reverse() method from django.urls which as moved from
django.core.urlresolvers.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
It is no longer very important to show Django configured applications
and module import messages because in practice we have rarely ever seen
being useful anywhere but for development. Just print the module load
order just once.
- 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.
When modules were removed, Debian packaging also had to remove them to
avoid errors. When Debian guidelines are following and correspoding deb
helper is used, it creates .dpkg-* files in the module configuration
directory. Plinth tries to load these which causes problems. We should
consider loading files with a known extension in future.
