Proposal # 1 > Ubuntu centric (debian packaging) If anything debian centric (debian packaging) ;) Adding a rpm-package.py command is neither helped or hindered by making the template modular. Quickly is modular, I wrote an app for my wife even though I didn't have a ppa. It is only the template that isn't modular. I'm not sure about the effect of python-distutils-extra, it automatically puts the project help files into the gnome help files directories.
Proposal #2 >Make the root template gtk-application and make ubuntu-application >descend from it like this. This would also need qt-application - kde-application - kubuntu-application, instead of the non-existent kubuntu-application ! ubuntu-application-vala will work equally well whether the base *python* template has "import LaunchpadIntegration" or not. The class that has "import LaunchpadIntegration" subclasses a gtk class so has little bearing on the design of the kubuntu-application template (aka ubuntu-application-kde). Proposal #3: Fork ubuntu-application Forking means that improvements and bug fixes in ubuntu-application does not get into gtk-application without extra work. For instance one-icon didn't get into pygame but probably should have. An alternative to forking would be to "patch" ubuntu-application inside template/gtk-application/create.py by using update_file_content(...) say to replace "import LaunchpadIntegration" by "\n" etc. Removing code is like this is far more difficult than adding code. Imagine the case where a upgrade to ubuntu-application changes "import LaunchpadIntegration" to "import LaunchpadIntegration, another_module". Having a gtk-template and an add "import LaunchpadIntegration\n" inside template/ubuntu-application/create.py or as a standalone add command is likely to be more robust. On 23/12/2010, Michael Terry <michael.te...@canonical.com> wrote: > On Thu, 2010-12-23 at 09:40 -0500, Michael Terry wrote: >> I imagine that long term, it's easier to move template code into the >> quickly python library for use in multiple templates than create >> complicated hierarchies of templates. (would we allow multiple >> inheritance [1], how often would we correctly guess where a bit of code >> belongs, would it make it easier or harder to write templates) > > For a bit of low-hanging-fruit/proof-of-concept refactor, I just filed a > new merge: > > https://code.launchpad.net/~mterry/quickly/small-refactor/+merge/44606 > > This just moves some deb and LP logic into submodules of the 'quickly' > module. > > Further work could see pulling out python-project-handling logic into a > 'build.python' submodule or something... > > -- > mterry > > > _______________________________________________ > Mailing list: https://launchpad.net/~quickly-talk > Post to : quickly-talk@lists.launchpad.net > Unsubscribe : https://launchpad.net/~quickly-talk > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~quickly-talk Post to : quickly-talk@lists.launchpad.net Unsubscribe : https://launchpad.net/~quickly-talk More help : https://help.launchpad.net/ListHelp
