quickly-talk team mailing list archive

[Alistair Buxton <a.j.buxton@xxxxxxxxx>]

On 8 August 2012 08:25, Didier Roche <didrocks@xxxxxxxxxx> wrote:

> We can support different hosting systems the same way we can support
> different languages/technologies. This is then by creating other templates.
> Also, if you have good code encapsulation, we can put the git part to the
> quickly templatetools library as we will with bzr (and as we did with
> launchpad for instance) so that creating a template will be easier.
>
> We want to make template easier to create and not inherit "all or nothing"
> from another template commands, that's why I envision the new commands to be
> that way:
>
> from quickly.templates import Command
>
> class Create(Command):
> def run(self):
> '''Core part of the command, piloting other methods'''
> self.do_a()
> self.do_b()
> self.do_c()
> self.do_d()
>
> then, do_a, do_b, do_c, will be functional logical part of the command. So,
> if there are bzr commands for instance, they will be in a:
>
> def do_b(self):
> templatestools.bzr.save()
>
> def do_c(self):
> launchpad= templatestools.launchpad.get_cred()
> launchpad.create_project(self.project_name)
> launchpad.publish_command(…)
>
> so, if you want to create a new template inheriting from those, you can:
>
> from quickly.templates.ubuntu_application import Create as UbuntuappCreate
>
> class Create(UbuntuappCreate):
>
> def do_b(self):
> '''use git'''
>
> def do_c(self):
> '''use github'''
>
> As all python functions are virtual, this is what I think is a good
> compromise. We still need a way to import some "bare metals" command without
> modifying them maybe (or juts asking for an subclassing with pass in it, no
> strong opinion on that). At least, it's an explicit declaration of what is
> imported, what is really overriden (like no submitubuntu template in this
> derivate template and a new tutorial template).
>
> Now comes to the question of the boiler plate. We can figure something out
> so that you can import the boiler plate from another template without having
> to copy it, and having the command launched in the context of the other
> template, as it's already the case here.
>
> So .commandsconfig will have some metadata for this.
>
> It seems to me to be a less complicated design, which can grow way more
> sanely and harmoniously in the future to the new requests. It enables you to
> achieve your different hosting goal in a new template without having to copy
> the boiler plate and to maintain the whole command.
> What do you think?

This system does not address the exponential number of different
templates that will result. It creates unnecessary additional work for
template maintainers, and it means users have to wait for the template
they want to use to be ported to their desired hosting service. It
causes the template library to be extremely large and fragmented, and
forces the user to look at the template to determine which hosting
system it supports.

-- 
Alistair Buxton
a.j.buxton@xxxxxxxxx