- setuptools aims to a build library instead of being invoked by setup.py.
Launching setup tools using ./setup.py is deprecated. Launching it using
generic build tools that use pyproject.toml is recommended.
- With the new approach customizing the build is not possible to the earlier
extent. So, introduce is a simple and sufficient build system using 'make'.
Tests:
- Check the pyproject.toml using validate-pyproject tool.
- Run diffoscope on old and new packages and verify that no unexpected changes
were introduced by the build system change.
- None of the files part of .deb package have different file permissions
compared to before.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Tests:
- mypy does not show any errors.
- Installing ejabberd app works. Privileged actions run fine.
- Unit tests work.
- No additional testing was done as type annotations don't have any effect at
runtime.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- This will leave /etc/{plinth,freedombox} empty by default making service more
robust to run across various environments and situations. See systemd's
explanation for more details.
- Use Debian maintainer scripts remove all the existing files in
/etc/plinth/modules-enabled.
- Read from /usr/share/freedombox/modules-enabled then from
/etc/plinth/modules-enabled and finally from /etc/freedombox/modules-enabled.
Later read ones override previously read files. Any file pointing to /dev/null
will mean the module must be ignored.
Tests:
- Clean up /etc/plinth, /etc/freedombox and
/usr/share/freedombox/modules-enabled. Run service and notice that files are
getting loaded from development folder using a debug message.
- Run setup.py and notice that files get installed in
/usr/share/freedombox/modules-enabled/ and in the next run they get loaded from
there.
- Create a override file in /etc/plinth/modules-enabled/transmission and notice
that overriden file gets priority over the one in
/usr/share/freedombox/modules-enabled.
- Link the file /etc/plinth/modules-enabled/transmission to /dev/null and notice
that is not loaded.
- Create another file in /etc/freedombox/modules-enabled/transmission and notice
that it overrides the previous two files.
- All affected modules are loaded.
- Build a new Debian package and ensure that upgrading 23.8 to new version
removes are all configuration files.
- Build developer documentation and test that Tutorial -> Full Code and Tutorial
-> Skeleton sections have been updated with references to
-.../modules-enabled/... paths.
- Install quassel and notice that certificates were copied to /var/lib/quassel
directory. Change domain to another domain and notice that certificates were
copied again to that directory.
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Any privileged action (a method) can be marked as such with the new decorator. A
call to the method will be serialized into a sudo call (or later into a D-Bus
call). The method arguments are turned to JSON and method is called as
superuser. Arguments are de-serialized and are verified for type before the
actual call as superuser. Return values are serialized and returned where they
are de-serialized. Exceptions are also serialized and de-serialized.
The method must have be strictly typed and should not have keyword-only
arguments. Currently supported types are int, float, str, dict/Dict, list/List
and Optional.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Don't try to get the depends from module level and sort modules based on that.
- Instead after all App instances are created, sort the apps based on
app.info.depends and app.info.is_essential.
- Print message that apps have been initialized instead of printing before they
are initialized. The correct order of apps is only known after they have been
initialized and sorted.
- Avoid circular import on module_loader and setup.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Loading module is only for importing python modules and determining the order
in which they should be loaded.
- Initializing apps will create the instances which involves just creating the
components of the apps.
- Post initialization involves connecting to signals, running configuration
fixes, etc.
Tests:
- All apps that have post initialization step have been tested.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- In Django 2.2 django.conf.urls.url() is an alias to django.urls.re_path().
- In Django 4.0, url() function will be removed. On Django 3.2, it throws a
warning that this function will be removed in future.
Tests:
- Run unit tests with Django 3.2 and Django 2.2.
- With Django 3.2 there are no warnings when running unit tests and when running
FreedomBox Service.
- Visit a few affected apps with both Django versions.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Drop message for initialization of each app. This was removed earlier but was
reintroduced during init() refactoring. There is not much use for these messages
and the noise they generate hide some important messages relating to domains
added.
- Print lists in a better way for humans.
- Add a log message after all the initialization is completed.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Since modules need not have dependency on any essential module even though they
are dependent on them, it must be assumed that any module may depend on any
essential module. So, load or process (like running setup) essential modules
before non-essential modules.
Closes: #1967.
Tests:
- When service is started, console messages show that in the module load order,
all the essential modules are prioritized.
- Without these changes, this is not the case.
- When version of essential app and non-essential app are incremented, essential
app is setup before the non-essential app.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
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.
