quickly-talk team mailing list archive

[tony byrne <tony.badwolf@xxxxxxxxx>]

---------- Forwarded message ----------
From: tony byrne <tony.badwolf@xxxxxxxxx>
Date: Wed, 8 Aug 2012 18:37:22 +0100
Subject: Re: [Quickly-talk] Proposal: Abstract hosting service from
project templates.
To: Alistair Buxton <a.j.buxton@xxxxxxxxx>

Hi Alistair
 I reread your proposal and I overlooked "release". Consider a githost
template whose job is to perform the one line edits required and
"release". It doesn't contain or import a create command. It doesn't
contain any project files.
Put githost.py and release.py in this templates directory.

quickly create ubuntu-application foo
cd foo
edit .quickly to rebase the project to your githost template.
quickly githost (githost.py performs the edits)
quickly release (release is in the githost template)

On 08/08/2012, tony byrne <tony.badwolf@xxxxxxxxx> wrote:
> Hi Alistair
>  One thing I found annoying about quickly templates was it's
> opinionated monolithic nature. I did some work on "add" to wrest
> control of projects away from the quickly team. The modular system
> builds upon "add" but "add" alone will solve your problem, I think.
>
> Create a template, I call mine toolbox, based on any existing
> template, I use ubuntu-cli. The project files in here won't be used in
> any way so it doesn't matter. Edit the commandsconfig file to import
> "add" ,create a directory ~/quickly-templates/toolkit/store and create
> a file ~/quickly-templates/toolkit/store/githost.py.
>
> Now when you start a project you can do this
> quickly create ubuntu-application foo
> cd foo
> quickly -t toolbox add githost
>
>  Obviously you need to put some content into githost.py to perform the
> one line edit to several project files you spoke about. I hope this
> helps.
>
>
>
> On 08/08/2012, Alistair Buxton <a.j.buxton@xxxxxxxxx> wrote:
>> 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
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~quickly-talk
>> Post to     : quickly-talk@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~quickly-talk
>> More help   : https://help.launchpad.net/ListHelp
>>
>