fab-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fab-user] Any interest in extension to support getting things from


From: Jeff Forcier
Subject: Re: [Fab-user] Any interest in extension to support getting things from source control?
Date: Fri, 9 Oct 2009 10:02:58 -0400

Hi guys,

tl;dr version: it *may* make sense to add contrib SCM support, but
only if there's a demonstrated need for something greater than
'run("my_scm_tool (clone|checkout) repository_url")' :) Anyone with
that sort of need, please pipe up with some use cases!

Full replies below.

> On Oct 6, 2009, at 10:58 PM, Jeremy Katz wrote:
>
>> is there any interest in having some
>> actual support for pulling files from source control?

There is interest; I think other users have mentioned it before, and I
was thinking of putting it in sometime, if it could be done well and
unobtrusively, and if there's an actual need for anything more
involved than "run('git clone git://foo.com/bar.git')".

If you could provide a quick overview of what you'd like to do and how
something built in to Fabric would make your life easier, please do!


On Fri, Oct 9, 2009 at 9:30 AM, Steve Steiner (listsin)
<address@hidden> wrote:
>
> I think this type of thing is best left out of a product like Fabric or,
> next thing you know, it'll sprout a mail reader.

I am *definitely* interested in preventing feature creep, and don't
want fabric.contrib to start looking like e.g. Python's stdlib; I
don't plan on including everything pitched my way :)

My "contrib" philosophy is like Django's -- if there is a relatively
obvious "best practices" approach to something, and having users
always do it themselves feels like reinventing the wheel, it *may* be
a good fit. SCM could fit that bill, again if anyone can come up with
some common patterns that span more than a couple of lines of
run/sudo.


On Fri, Oct 9, 2009 at 9:47 AM, Ask Solem <address@hidden> wrote:
>
> I'd vote no to having it as part of fabric itself, at least as the de-facto
> way of deploying projects. Which seems to be the case in the Ruby community.

I certainly agree with this: I don't really want Fabric to be pushing
any specific or de-facto deployment methodology. It should be a
collection of tools that users use as is appropriate to their needs.
If SCM support of any kind is added, it would simply be an additional
module in fabric.contrib -- just another tool in the toolbox.


Best,
Jeff




reply via email to

[Prev in Thread] Current Thread [Next in Thread]