Profile Layer next steps: Templates

[Fran Boon]

As per previous discussions on the list we would like to have a common
storage location for Deployment Templates, Prepop Data & Theme.
Previously we have called this the 'Profile Layer' but some have
objected to this terminology so we're now proposing the term
'Template' for this.
I would like to propose that we take the next step on this path which
is to bring together deployment templates & prepop data.
(Theme will unfortunately have to come at a later date).
The value that I see in getting this step done is:
* Less merge conflicts between different deployment branches
* Easier to get set up to run Testing of different Workflows
* Easier to get set up to do different Trainings/Demos

Proposal on Specific Steps:
* Rename private/prepopulate as private/templates
* Move 000_config.py from deployment_templates/models to
private/templates/config_default.py
* Go through it to complete making as many lines as possible be
commented (default provided by modules/s3cfg.py)
* Delete deployment_templates folder (deprecated)
* Move countries.csv from private/import to private/templates/default
* Update zzz_1st_run to locad countries from this new location
* Delete private/import folder (old content best put elsewhere)
* Delete private/examples folder (old content best put elsewhere)
* Move update_check from private to modules (keep code separate from data)
* Amend it to write a 'TEMPLATE=False' line (& helptext similar to
which exists with the prepop setting in 000_config currently) to
0000_template.py.
* This replaces both the 0000_update_check.py & the
FINISHED_EDITING_CONFIG_FILE in 000_config
* If TEMPLATE != False then use this to copy a config.py from the
selected template folder (falling back to config_default.py) & run
prepop for the specified template.
* Update Documentation: i.e. Wiki & Book

I am aware that this will cause a 1-time significant merge conflict. I
am totally prepared to provide personal assistance to anyone through
that if-necessary.

Does anyone have any questions or concerns about this?

Any improvements to the plan?

Many thanks,
Fran.

[Pat Tressel]

As per previous discussions on the list we would like to have a common
storage location for Deployment Templates, Prepop Data & Theme.
Previously we have called this the 'Profile Layer' but some have
objected to this terminology so we're now proposing the term
'Template' for this.
I would like to propose that we take the next step on this path which
is to bring together deployment templates & prepop data.
(Theme will unfortunately have to come at a later date).
The value that I see in getting this step done is:
* Less merge conflicts between different deployment branches
* Easier to get set up to run Testing of different Workflows
* Easier to get set up to do different Trainings/Demos

Proposal on Specific Steps:
* Rename private/prepopulate as private/templates
* Move 000_config.py from deployment_templates/models to
private/templates/config_default.py

Will different templates have their own distinct sets of configuration variables (a la Wordpress themes) or would that be discouraged or handled out-of-band?  That is, will a template only be a set of choices of settings defined in the base code, or can templates add code?
 

* Go through it to complete making as many lines as possible be
commented (default provided by modules/s3cfg.py)
* Delete deployment_templates folder (deprecated)
* Move countries.csv from private/import to private/templates/default
* Update zzz_1st_run to locad countries from this new location
* Delete private/import folder (old content best put elsewhere)
* Delete private/examples folder (old content best put elsewhere)
* Move update_check from private to modules (keep code separate from data)

Ok so long as the parts that move to modules only need to be updated on the same schedule as modules.  Some of the "code" in update_check is actually serves the function of data.  If we want to make it truly data-driven, we'd have to define a data structure to represent the tests, so the generic check code could just execute each data-specified test in turn.
 

* Amend it to write a 'TEMPLATE=False' line (& helptext similar to
which exists with the prepop setting in 000_config currently) to
0000_template.py.
* This replaces both the 0000_update_check.py & the
FINISHED_EDITING_CONFIG_FILE in 000_config
* If TEMPLATE != False then use this to copy a config.py from the
selected template folder (falling back to config_default.py) & run
prepop for the specified template.
* Update Documentation: i.e. Wiki & Book

I am aware that this will cause a 1-time significant merge conflict. I
am totally prepared to provide personal assistance to anyone through
that if-necessary.

The trick is to identify sites that are using the code that we aren't in active contact with currently, or to (automatically) alert sites that do an update that they're in for some work.  Not sure if git can be made to do this, but we could add a README_NO_REALLY_WE_MEAN_IT file.  Would be nice to encourage potential users to fork the code on Github rather than just cloning it or (worse) copying it without revision data.
 

Does anyone have any questions or concerns about this?

Any improvements to the plan?

-- Pat

[Fran Boon]

On 20 May 2012 15:32, Pat Tressel <ptre...@myuw.net> wrote:
> Will different templates have their own distinct sets of configuration
> variables (a la Wordpress themes) or would that be discouraged or handled
> out-of-band?  That is, will a template only be a set of choices of settings
> defined in the base code, or can templates add code?

Some customisation elements may need some code rather than being pure
data - e.g. the menu & layout.
The parsing routines for Incoming messages developed this GSoC would be another.
There may be yet more that I don't currently have visibility of.
Do you have specific thoughts here?

>> * Move update_check from private to modules (keep code separate from data)
> Ok so long as the parts that move to modules only need to be updated on the
> same schedule as modules.  Some of the "code" in update_check is actually
> serves the function of data.  If we want to make it truly data-driven, we'd
> have to define a data structure to represent the tests, so the generic check
> code could just execute each data-specified test in turn.

That could indeed be a useful task...although wouldn't need to be done
during this iteration.

>> I am aware that this will cause a 1-time significant merge conflict. I
>> am totally prepared to provide personal assistance to anyone through
>> that if-necessary.
> The trick is to identify sites that are using the code that we aren't in
> active contact with currently, or to (automatically) alert sites that do an
> update that they're in for some work.

You're right that we should build in some kind of clear warning for
existing installs which are upgrading...I will factor this in.

Any site which is updating their code should really be on this mailing
list as currently this still requires some level of technical
engagement - we're not yet providing discrete upgrade packages to a
1.0 release.
I would love to be in a position to do that, but it's not where we're at now.

Of course, Production sites should be upgrading via staging sites, so
wouldn't have this affect Production users.

My sense is that most independent installs are either in no-dev mode
or else still in dev trials anyway.

> Would be nice to
> encourage potential users to fork the code on Github rather than just
> cloning it or (worse) copying it without revision data.

I think many potential users don't want to have to code - they just
want to be able to do a minimal amount of configuration.

F