worked in dev guide

docs/about/more.rst

@@ -10,10 +10,8 @@ More about Lino
    testimonals
    name
    history
-   lino_and_django
    thanks
    art
-   ui
    customized
    desktop
 

docs/about/ui.rst

@@ -18,13 +18,20 @@ interfaces.
 
 **In practice**, your choice is currently limited to the
 :mod:`lino.modlib.extjs` UI.  Lino applications currently "look like"
-those you can see at :doc:`/demos`.  But that's just because
-:term:`extjs` is so cool, and because writing and optimizing a user
+those you can see at :doc:`/demos`.
+
+But that limit exists just because writing and optimizing a user
 interface is a rather boring work, and because there are many other,
-more interesting tasks that are waiting to be done.
+more interesting tasks that are waiting to be done, and, last but not
+least, because :term:`extjs` is so cool.
+
+One might consider Lino's :class:`TextRenderer
+<lino.core.renderer.TextRenderer>` (used for writing :doc:`tested
+functional specifications </dev/doctests>`) as a special kind of user
+interface.
 
-There are several proofs of concept for Lino's user interface
-transparency:
+There are several proofs of concept for alternative Lino's user
+interfaces:
 
 - the :mod:`lino_extjs6` is almost ready for production.
 - a more lightweight web interface using some other JS framework than ExtJS
@@ -38,11 +45,6 @@ transparency:
   <https://en.wikipedia.org/wiki/Qt_%28software%29>`_ or `wxWidgets
   <https://en.wikipedia.org/wiki/WxWidgets>`_
 - an XML or JSON based HTTP interface
-- one might consider Lino's :class:`TextRenderer
-  <lino.core.renderer.TextRenderer>` (used for writing tested
-  functional specifications like `this one
-  <http://welfare.lino-framework.org/specs/households.html>`_) as a
-  special kind of user interface.
 
 There is a more detailed overview on :doc:`what this means for the
 developer </dev/ui>`.

docs/community/developers.rst

@@ -15,10 +15,6 @@ language and invest their time into Lino.
   application.  Your advantage is that you get a free mentorship and
   increase your chances on the job market.
 
-Developers can be either **voluntary** contributors or **employed** by
-some company.  Currently we know that `Rumma & Ko is hiring
-<http://www.saffre-rumma.net/jobs/coredev>`__.
-
 We can also differentiate developers by their *primary motivation*:
 
 - **Core developers** help us to make Lino better.  This includes the
@@ -28,5 +24,8 @@ We can also differentiate developers by their *primary motivation*:
 - **Application developers** write their own independent Lino
   applications and publish them using their preferred license.
 
-
+Developers can be **voluntary** contributors, independant
+**freelancers** or **employed** by some company.  Currently `Rumma &
+Ko is hiring <http://www.saffre-rumma.net/jobs/coredev>`__.  There
+might be other companies offering Lino development.
 

docs/community/hosters.rst

@@ -1,3 +1,5 @@
+.. _hosting_provider:
+
 ======================
 Lino hosting providers
 ======================
@@ -20,18 +22,16 @@ the following responsibilities:
 
 There are two types of hosting:
 
-- in case of **stable hosting** the hoster also gives you end-user
-  support and regular maintenance (i.e. they answer your questions
-  about how to use or configure the software, and they are able
-  upgrade your site when new versions of the software are available).
-
 - in case of **development hosting** the hoster is *not reponsible*
-  for these services, that's is the job of a :doc:`developer
-  <developers>`).
+  for *end-user support* and *regular maintenance*.  You need a second
+  agreement with a :doc:`developer <developers>` for these.
 
-
-.. _hosting_provider:
+- in case of **stable hosting** the hoster also offers these services,
+  i.e. they answer your questions about how to use or configure the
+  software, and they are able upgrade your site when new versions of the
+  software are available.
 
+
 
 List of recommended Lino hosting providers
 ==========================================

docs/dev/demo_projects.rst

@@ -0,0 +1,23 @@
+.. _lino.dev.demo_projects:
+
+===================
+About demo projects
+===================
+
+Every code repository can come with a series of demo projects.
+
+A demo project is a project in the Django meaning of the word: a
+directory where you can go and run django-admin commands.
+
+Demo projects are used for testing, documentation and demonstration
+purposes.
+
+They are defined with the :envvar:`demo_projects` in the repository's
+:xfile:`tasks.py` file.
+
+They contain fictive data generated using Python fixtures.
+
+:cmd:`inv prep` initializes all demo projects of a repository.
+
+You can manually initialiae a single demo project by going to it's
+directory and running :manage:`initdb_demo`.

docs/dev/index.rst

@@ -62,15 +62,17 @@ Your first application
 
 
 
-Why you want Lino
-=================
+The Lino design choices
+=======================
 
-When you arrived here, you should be able to understand the
-fundamental differences between Lino and other frameworks.
+Now we think it is time to explain some fundamental differences
+between Lino and other frameworks.
 
 .. toctree::
    :maxdepth: 1
 
+   /about/ui
+   /about/lino_and_django
    /about/not_easy
    /about/think_python
    ui
@@ -236,9 +238,10 @@ Drafts
    /tutorials/myroles/index
    workflows
    translate/index
-
-   testing
 
+   demo_projects
+   testing
+   doctests
    help_texts
    userdocs
    signals

docs/dev/testing.rst

@@ -1,35 +1,66 @@
 .. _dev.testing:
 
 
+=========================
 Testing Lino applications
 =========================
 
 You can write test suites for a Lino application like for any other
-Django project.
+Django project. But Lino adds a set of tools, conventions, ideas and
+suggestions for testing your applications.
+
+Running classical Django tests
+==============================
+
+Any given *code repository* usually corresponds to one *Python
+package* and has one *test suite*.
+
+
+The test suite of a Python package is defined in
+:xfile:`setup_info.py`.
+
+In most of our projects this contains a single file
+:file:`tests/__init__.py` which is if you want the "master file".
+
 
-Lino adds to Django a set of tools, conventions, ideas and suggestions 
-for testing your applications.
+A Python package can contain multiple demo projects.  A typical test
+is to run Django's :manage:`test` command in each of them. Something
+like this (excerpt from the :file:`tests/__init__.py` of
+:ref:`book`)::
 
-Demo databases.
+    from lino.utils.pythontest import TestCase
 
-Lino adds a new style of test cases: 
-test cases that use a `django.test.Client`,
-but *on the project demo database* 
-and *not* on a test database as the Django test runner creates it.
+    class ProjectsTests(TestCase):
+
+        def test_min1(self):
+            self.run_django_manage_test("lino_book/projects/min1")
+
+You know that there is no way to test several Django applications in a
+single Python process. Every piece of code which imports Django
+requires the :envvar:`DJANGO_SETTINGS_MODULE` environment variable to
+be set, and it is not allowed to change that variable at runtime. So
+it is clear that every call to :meth:`run_django_manage_test
+<lino.utils.pythontest.TestCase.run_django_manage_test>` is going to
+spawn subprocess.
+
+
+Running doctests
+================
+
+Lino adds a new style of test cases: test cases that use a
+:class:`django.test.Client`, but *on a cached demo database* and *not*
+on a temporary test database as the Django test runner creates it.
 
 The advantage is that they access the existing demo database and thus
 don't need to populate it (load the demo fixtures) for each test run.
 
 A limitation of these cases is of course that they may not modify the
-database.
+database. That's why we sometimes call them static or passive. They
+just observe whether everything looks as expected.
 
 All these would deserve a whole chapter of documentation.  I'll do my
 best to fill up this hole...  meanwhile you must use the source, Luke!
 
-.. toctree::
-
-    tested_docs
-
 
 - Extended TestCase classes:
 

tests/__init__.py

@@ -235,7 +235,7 @@ def test_ajax(self):
         self.run_simple_doctests('docs/specs/ajax.rst')
 
 
-class ProjectsTests(LinoTestCase):
+class ProjectsTests(TestCase):
 
     # def test_all(self):
     #     from atelier.fablib import run_in_demo_projects