Encapsulate all customization in a playdoh module for easy upgrading

[kumar303]

Playdoh does custom things to Django in manage.py and elsewhere -- when this logic changes it will be hard to update existing Playdoh apps that are not direct clones of playdoh (say, an old Django app converted to playdoh). One way to solve this would be to create a playdoh core module to encapsulate all customizations. For example, manage.py would become:

from playdoh import manage
manage.setup_environ()
if __name__ == '__main__':
    manage.main()

Consider this patch to Playdoh's distributed manage.py file: https://github.com/jbalogh/test-utils/blob/master/test_utils/runner.py#L100 This is going to be hard to apply to existing projects that aren't git clones. Each developer would have to copy/paste the new manage.py and any other file.

The same thing is true of default settings -- if any default setting changes then you'd have to copy/paste. Instead, settings_local.py file could start with this import:

from playdoh.settings import *

If playdoh was a standalone module then upgrading an existing app would be as simple as upgrading the playdoh module -- everything would work as long as the APIs remained the same.

[erikrose]

Yes, that. Less generated/cloned code ftw.

[davedash]

This may or may not be the place for it... playdoh as the name suggests is meant to be molded into something useful. A secondary project to contain all these things might be the place to put our custom management APIs, etc. What this might result in is less moving parts in playdoh, and more parts moving in mozilla/funfactory... the engine that powers playdoh...

[kumar303]

I'm not suggesting adding more customization, I'm just suggesting to move the current customization into a Python module so that there is a central location for it. Another way to put it is this: Let's make the current directory layout of playdoh something that will never ever change (if possible). And let's push all the custom code into a module. That way no one will ever need to patch their manage.py or their base settings.py; they would just need to upgrade the playdoh module in the apps directory (or vendor, wherever). Does that make more sense?

Also, even for people who are working with a git clone, keeping all customizations in a separate playdoh module would minimize conflicts when pulling from the playdoh repository.

[erikrose]

Yep. To summarize, be a library as much as possible; a template as much as necessary.

[jsocol]

As I understood Dave, playdoh (the template) would use this module (funfactory, or whatever) that other projects could also trivially drop in without needing to update their directory structure to match playdoh--that would be great.

[erikrose]

Another advantage of library-fication!

[kumar303]

playdoh is now librarified! To follow incremental extraction of logic see:

a63674e
then
a39d162

and for the real fun ...
https://github.com/mozilla/funfactory

Let me know if you guys see any glaring issues or if I broke something.

[kumar303]

All apps/commons have moved to funfactory. We have now reached full librarification (I think). See mozilla/funfactory@d6e3776

[davedash]

Should funfactory get doc'd in playdoh-docs?

My guess is yes. And if so, can you add a sections on: 1. Patching an existing app to use funfactory (with a special note for existing playdoh/apps/commons users) and 2. Upgrading funfactory.

Thanks, this is quite nice.

[kumar303]

Docs! http://playdoh.readthedocs.org/en/latest/upgrading.html