What do you want ZF2 tool to be?

[Artur Bodera]

Hey friends!

Remember zf1 Zend_Tool? You could do things like:

    # zf show version

    # zf create project

    # zf create controller Foo

    # zf create model Bar 

etc.

Now we have zf2 with modules. I've built (and am currently refactoring to latest

master) the Zend\Console component which handles CLI commands and sends

them to actions (in controllers in modules).

In the meantime, we've done the following:

    1. ZF2 components are now segmented and can be installed via Composer.

    2. ZF2 modules encapsulate all app logic and misc. functionality (3rd party mods)

    3. There is no "preferred" way to install zf2, there are many.

I want to bring back "The Tool" to ZF2, but there are couple of questions I'd like

YOU to answer. 

So the main question is:

What would new ZF2 ZendTool really be ?

   1. A self-contained PHP script + bash/cmd wrapper that performs some very basic install tasks?

   2. A self-contained mini zf2 application (i.e. PHAR-ed) that performs tasks ?

   3. A module that's copied to vendor/ of existing app in order to use it ?

   4. A hybrid? a self-contained script that later installs itself as a module ? 

   5. Skeleton-app extension, PR actually ?

Where would it be at ?

   1. Optional download ?

   2. Shipped with zf2 in bin/ 

   3. Optional, fetched via another (lightweight) script living in zf2 bin/ ?

--
      __
     /.)\   [phone]
     \(./   [hidden email]

[Jurian Sluiman-3]

2012/6/17 Artur Bodera <[hidden email]>

What would new ZF2 ZendTool really be ?

   1. A self-contained PHP script + bash/cmd wrapper that performs some very basic install tasks?

   2. A self-contained mini zf2 application (i.e. PHAR-ed) that performs tasks ?

   3. A module that's copied to vendor/ of existing app in order to use it ?

   4. A hybrid? a self-contained script that later installs itself as a module ? 

   5. Skeleton-app extension, PR actually ?

I would like to have a CLI application doing the same with MVC as http: have a Request and (possibly) return a Response. That way I can reuse many things from my main development goal: MVC implementations where I create controllers/models/services/view scripts etc. The tasks that it therefore can perform might include a wide variety of goals.

That said, I think it is good to look at CLI applications from Doctrine and/or Symfony. Those kind of CLI tools is what I would like to expect: create sql structures for my database, copy assets to a public directory: kind of framework/application specific (deployment) actions. However, it might have a great overlap with Phing for example. I would suggest ZF2 Tool would not be a replacement for Phing, as it's useless additional work for you and we can better point everybody towards Phing.

Where would it be at ?

   1. Optional download ?

   2. Shipped with zf2 in bin/ 

   3. Optional, fetched via another (lightweight) script living in zf2 bin/ ?

Zend\Console is now a component and I am happy it's there. I think the entry point for cli apps should be like the public/index.php and as slim as possible, preferably in bin/. Then, if you talk about ZendTool as a default provider for ZF2 specific actions, I'd assume you put that into a module (and a separate module). The ZendTool module could for example create a scaffold module structure at a given location.

--
Jurian Sluiman

[Sascha-Oliver Prolic]

2012/6/17 Artur Bodera <[hidden email]>:

> Hey friends!
>
> Remember zf1 Zend_Tool? You could do things like:
>
>     # zf show version
>     # zf create project
>     # zf create controller Foo
>     # zf create model Bar
> etc.
>
> Now we have zf2 with modules. I've built (and am currently refactoring to
> latest
> master) the Zend\Console component which handles CLI commands and sends
> them to actions (in controllers in modules).
>
> In the meantime, we've done the following:
>     1. ZF2 components are now segmented and can be installed via Composer.
>     2. ZF2 modules encapsulate all app logic and misc. functionality (3rd
> party mods)
>     3. There is no "preferred" way to install zf2, there are many.
>
> I want to bring back "The Tool" to ZF2, but there are couple of questions
> I'd like
> YOU to answer.
>
>
> So the main question is:
>
> What would new ZF2 ZendTool really be ?
>
>    1. A self-contained PHP script + bash/cmd wrapper that performs some very
> basic install tasks?
>    2. A self-contained mini zf2 application (i.e. PHAR-ed) that performs
> tasks ?
>    3. A module that's copied to vendor/ of existing app in order to use it ?
>    4. A hybrid? a self-contained script that later installs itself as a
> module ?
>    5. Skeleton-app extension, PR actually ?
>
>
> Where would it be at ?
>
>    1. Optional download ?
>    2. Shipped with zf2 in bin/
>    3. Optional, fetched via another (lightweight) script living in zf2 bin/
> ?
>
>
> --
>       __
>      /.)\   [phone]
>      \(./   [hidden email]

What would new ZF2 ZendTool really be ?

Definitly 3. A module that's copied to vendor! I see no reason, why
this should not be a module. This answers already your next question:
Where would it be at ? - a simple public git repository with a module
inside ;-). best with composer.json. So installation is very easy
performed with the current recommended installation procedure
(composer!).

Best Regards

--
Sascha-Oliver Prolic

[Chris Testroet]

On 6/17/2012 7:42 AM, Artur Bodera wrote:

> What would new ZF2 ZendTool really be ?
>
>    1. A self-contained PHP script + bash/cmd wrapper that performs
> some very basic install tasks?
>    2. A self-contained mini zf2 application (i.e. PHAR-ed) that
> performs tasks ?
>    3. A module that's copied to vendor/ of existing app in order to
> use it ?
>    4. A hybrid? a self-contained script that later installs itself as
> a module ?
>    5. Skeleton-app extension, PR actually ?
>
>
> Where would it be at ?
>
>    1. Optional download ?
>    2. Shipped with zf2 in bin/
>    3. Optional, fetched via another (lightweight) script living in zf2
> bin/ ?
>

I like the idea of a lightweight script in bin/ that can handle a few
commands. Like determining version (PHP, ZF,extensions), phpinfo,
initializing an application with the ZendSkeletonApp, and installing a
tool module in the app that would allow application specific commands.
When the app is "current" (whatever that may mean) that additional
functionality will appear.

Additionally there are two features I'd like to request.
   1. An interactive mode.
   2. A much more compact and natural system for handling arguments.
instead of `action ModuleName controller_name action_name` I think it
should support a very forgiving single parameter that could be something
like:
`action module_name.controller_name.action_name` or `action
ModuleName.ControllerName.ActionName`

Chris

[Artur Bodera]

On Sun, Jun 17, 2012 at 5:00 PM, Jurian Sluiman <[hidden email]> wrote:

I would like to have a CLI application doing the same with MVC as http: have a Request and (possibly) return a Response. That way I can reuse many things from my main development goal: MVC implementations where I create controllers/models/services/view scripts etc. The tasks that it therefore can perform might include a wide variety of goals.

That's mostly already done with Zend\Console. It routes CLI command to one of your controllers which can return a string (which is then output to console) or use $console-> methods to generate some funky console output.

 

That said, I think it is good to look at CLI applications from Doctrine and/or Symfony. Those kind of CLI tools is what I would like to expect: create sql structures for my database, copy assets to a public directory: kind of framework/application specific (deployment) actions. However, it might have a great overlap with Phing for example. I would suggest ZF2 Tool would not be a replacement for Phing, as it's useless additional work for you and we can better point everybody towards Phing.

Well, that's the idea here.

You write Console-aware modules (that have console-aware or console-ready actions within controllers). Each 3rd party module (i.e. Doctrine) can provide 1 or more controllers that will work in CLI environment + set of Console routes for actions (i.e. # zf generate doctrine model etc.)

Jurian - My question was more like this:

"How should the ZF2 built-in (branded) Tool look like and behave"

_NOT_ 3rd party Console-aware modules, but the most generic, basic Zend-branded tool that will be used to:

1) Enable/disable modules

2) Install additional modules

3) Show ZF2 version and each module version

4) Check for updates

5) Dump configuration

6) Generate app skeletons, add controllers, add actions etc.

 

We're now talking about the "Tool" that will be shipped with, or provided to ZF2 when we launch....

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

[Artur Bodera]

On Sun, Jun 17, 2012 at 5:02 PM, Sascha-Oliver Prolic <[hidden email]> wrote:

Definitly 3. A module that's copied to vendor! I see no reason, why
this should not be a module. This answers already your next question:
Where would it be at ? - a simple public git repository with a module
inside ;-). best with composer.json. So installation is very easy
performed with the current recommended installation procedure
(composer!).

Each of proposed options has it's up and downsides.

This option was also my first choice, but here are potential problems:

1) If Tool exists only as a module, then it needs ZF2 to work.

2) Because it's a module it requires one to manually download, install zf2 + set up a valid ZF2 application (with mod manager and configuration).
3) It's a classic "chicken and egg" paradox - it's a module that requires zf2 to work, but we might expect it to install zf2, which it requires [endwhile]

4) If you screw your application (i.e. config file syntax error, missing component etc.), Tool will not work at all.

5) You need to know how to set up and configure ZF2 before you use (basic) zf2 Tool.

In contrast, with ZF1 you could download the framework .tgz, extract and run #zf create project.

Ideally, with zf2 we could have something like (simplified example):

# cd /home/user/myapp

# wget http://www.zendframework.com/download/zf2-stable.tgz

# tar -xzf zf2-stable.tgz

# cd zf2

# zf create application

    Checking PHP version and extensions...

    Creating directories...

    Creating application module...

    Creating configuration...

    Done! Your application is now installed in /home/user/myapp

# zf create controller Admin

# zf install module ZfcUser

    Downloading ZfcUser from https://github.com/ZF-Commons/ZfcUser/zipball/master

    Extracting...

    Updating composer.json

    Done! Module is now installed and appears to be working correctly. 

# zf enable module ZfcUser

    Running tests on module...

    Updating config....

    Done! Module is now enabled.

etc.

    

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

[Roediger, Tim]

I would very much like to see a module installer for third party modules, and the Zend\Tool would probably be the right place to put that. Composer does a good job of pulling a module from github (or elsewhere), placing it in vendor, and setting up autoloading. After that, a Zend\Tool module installer, run from the command line would:

 

Scan modules and vendor (and other configured module directories) to generate a list of modules on disk.

Compare list of modules on disk this with the modules in application.config.php

The option is given to install any modules on disk not in application.config.php

 

Module install process has three steps:

Add module name to application.config.php – let the user choose position in the stack

Copy any local|global.php.dist files in module/config to app/config/autoload, and tell the user that these need to be edited

If it exists, run script module/install/install.php so the module can handle any further customised install on its own

 

Zend\Tool should have a uninstall also that essentially reverses the process and runs module\install\uninstall.php if it exists.

 

Anything that can make install simpler will help zf2 adoption.

 

Cheers,

 

Tim Roediger

 

From: Artur Bodera [mailto:[hidden email]]
Sent: Monday, 18 June 2012 4:29 AM
To: Sascha-Oliver Prolic
Cc: Zend Framework Contributors
Subject: Re: [zf-contributors] What do you want ZF2 tool to be?

 

On Sun, Jun 17, 2012 at 5:02 PM, Sascha-Oliver Prolic <[hidden email]> wrote:

Definitly 3. A module that's copied to vendor! I see no reason, why
this should not be a module. This answers already your next question:
Where would it be at ? - a simple public git repository with a module
inside ;-). best with composer.json. So installation is very easy
performed with the current recommended installation procedure
(composer!).

 

Each of proposed options has it's up and downsides.

 

This option was also my first choice, but here are potential problems:

 

1) If Tool exists only as a module, then it needs ZF2 to work.

2) Because it's a module it requires one to manually download, install zf2 + set up a valid ZF2 application (with mod manager and configuration).
3) It's a classic "chicken and egg" paradox - it's a module that requires zf2 to work, but we might expect it to install zf2, which it requires [endwhile]

4) If you screw your application (i.e. config file syntax error, missing component etc.), Tool will not work at all.

5) You need to know how to set up and configure ZF2 before you use (basic) zf2 Tool.

 

 

In contrast, with ZF1 you could download the framework .tgz, extract and run #zf create project.

 

Ideally, with zf2 we could have something like (simplified example):

 

# cd /home/user/myapp

# wget http://www.zendframework.com/download/zf2-stable.tgz

# tar -xzf zf2-stable.tgz

# cd zf2

# zf create application

    Checking PHP version and extensions...

    Creating directories...

    Creating application module...

    Creating configuration...

    Done! Your application is now installed in /home/user/myapp

# zf create controller Admin

# zf install module ZfcUser

    Downloading ZfcUser from https://github.com/ZF-Commons/ZfcUser/zipball/master

    Extracting...

    Updating composer.json

    Done! Module is now installed and appears to be working correctly. 

# zf enable module ZfcUser

    Running tests on module...

    Updating config....

    Done! Module is now enabled.

 

etc.

    

 

 

 

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

[Sascha-Oliver Prolic]

2012/6/17 Artur Bodera <[hidden email]>:

> On Sun, Jun 17, 2012 at 5:02 PM, Sascha-Oliver Prolic
> <[hidden email]> wrote:
>>
>> Definitly 3. A module that's copied to vendor! I see no reason, why
>> this should not be a module. This answers already your next question:
>> Where would it be at ? - a simple public git repository with a module
>> inside ;-). best with composer.json. So installation is very easy
>> performed with the current recommended installation procedure
>> (composer!).
>
>
> Each of proposed options has it's up and downsides.
>
> This option was also my first choice, but here are potential problems:
>
> 1) If Tool exists only as a module, then it needs ZF2 to work.
> 2) Because it's a module it requires one to manually download, install zf2 +
> set up a valid ZF2 application (with mod manager and configuration).
> 3) It's a classic "chicken and egg" paradox - it's a module that requires
> zf2 to work, but we might expect it to install zf2, which it requires
> [endwhile]
> 4) If you screw your application (i.e. config file syntax error, missing
> component etc.), Tool will not work at all.
> 5) You need to know how to set up and configure ZF2 before you use (basic)
> zf2 Tool.
>
>
> In contrast, with ZF1 you could download the framework .tgz, extract and run
> #zf create project.
>
> Ideally, with zf2 we could have something like (simplified example):
>
> # cd /home/user/myapp
> # wget http://www.zendframework.com/download/zf2-stable.tgz
> # tar -xzf zf2-stable.tgz
> # cd zf2
> # zf create application
>     Checking PHP version and extensions...
>     Creating directories...
>     Creating application module...
>     Creating configuration...
>     Done! Your application is now installed in /home/user/myapp
> # zf create controller Admin
> # zf install module ZfcUser
>     Downloading ZfcUser
> from https://github.com/ZF-Commons/ZfcUser/zipball/master
>     Extracting...
>     Updating composer.json
>     Done! Module is now installed and appears to be working correctly.
> # zf enable module ZfcUser
>     Running tests on module...
>     Updating config....
>     Done! Module is now enabled.
>
> etc.
>
>
>
>
>
>
> --
>       __
>      /.)\   [phone]
>      \(./   [hidden email]
>
>
>

I am trying to imagin how ZF-Tool could help setting up a ZF2 project.
1) wget http://framework.zend.com/zendtool.tar.gz
2) tar xf zendtool.tar.gz
3) cd zf2
4) zf create application

nice. let's try our current approach and compare:
1) git clone git://github.com/zendframework/ZendSkeletonApplication.git
2) cd ZendSkeletonApplication
3) php composer.phar install

so what i've learned. setting up a zf2 project with zend tool is
_more_ work, actually i need 4 commands vs. 3.
My conclusion. We don't need Zend Tool to create the skelleton
application, a simple ZF2 module is enough.

Best Regards

Sascha

--
Sascha-Oliver Prolic

[Artur Bodera]

On Mon, Jun 18, 2012 at 10:22 AM, Sascha-Oliver Prolic <[hidden email]> wrote:

nice. let's try our current approach and compare:
1) git clone git://github.com/zendframework/ZendSkeletonApplication.git
2) cd ZendSkeletonApplication
3) php composer.phar install

so what i've learned. setting up a zf2 project with zend tool is
_more_ work, actually i need 4 commands vs. 3.
My conclusion. We don't need Zend Tool to create the skelleton
application, a simple ZF2 module is enough.

That's not accurate and your example applies more to a knowledgeable developer than

average zf consumer :-)

1. First of all you should _not_ clone skeleton application (for several reasons).

2. Even if you did a "flat" clone and removed .git, one still needs to understand git to use that.

3. One requires composer to do what you did here.

4. However --- You are still free to do just that if you please (hence - multiple installation methods).

What we're thinking here is a lean installation and configuration tool that you can use to perform

90% of routine tasks related mostly to ZF2 architecture. For example, modules are zf2-specific

gizmo and there'd be no easier way to just #zf install fooModule (and optionally answer a few

interactive questions along the way). Same goes for #zf create application which can guide

you through the process.

It _might_ be a tad longer (from your perspective), but much easier for beginners.

On the other hand, once you've got your app set up, git nor composer won't help you with 

generation of user models, modules, installation, configuration, and other zf2-specific tasks.

That's where it'll come in handy.

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

[Sascha-Oliver Prolic]

2012/6/18 Artur Bodera <[hidden email]>:

> On Mon, Jun 18, 2012 at 10:22 AM, Sascha-Oliver Prolic
> <[hidden email]> wrote:
>>
>> nice. let's try our current approach and compare:
>> 1) git clone git://github.com/zendframework/ZendSkeletonApplication.git
>> 2) cd ZendSkeletonApplication
>> 3) php composer.phar install
>>
>> so what i've learned. setting up a zf2 project with zend tool is
>> _more_ work, actually i need 4 commands vs. 3.
>> My conclusion. We don't need Zend Tool to create the skelleton
>> application, a simple ZF2 module is enough.
>
>
>
> That's not accurate and your example applies more to a knowledgeable
> developer than
> average zf consumer :-)
>
> 1. First of all you should _not_ clone skeleton application (for several
> reasons).
> 2. Even if you did a "flat" clone and removed .git, one still needs to
> understand git to use that.
> 3. One requires composer to do what you did here.
> 4. However --- You are still free to do just that if you please (hence -
> multiple installation methods).
>
> What we're thinking here is a lean installation and configuration tool that
> you can use to perform
> 90% of routine tasks related mostly to ZF2 architecture. For example,
> modules are zf2-specific
> gizmo and there'd be no easier way to just #zf install fooModule (and
> optionally answer a few
> interactive questions along the way). Same goes for #zf create application
> which can guide
> you through the process.
>
> It _might_ be a tad longer (from your perspective), but much easier for
> beginners.
>
> On the other hand, once you've got your app set up, git nor composer won't
> help you with
> generation of user models, modules, installation, configuration, and other
> zf2-specific tasks.
> That's where it'll come in handy.
>
>
>
>
> --
>       __
>      /.)\   [phone]
>      \(./   [hidden email]

Well I am not against ZF Tool :-) We can ship a zf-tool.phar that
setups zf2 app + selfinstalls itself as module, so both win :-)

Best Regards

Sascha

--
Sascha-Oliver Prolic

[Tomáš Fejfar]

Obvious problem with the git-clone workflow is that not everyone is skilled enough to set up git (it's not trivial on Windows - you have to choose openssl vs peagant, etc - many devs have no idea WTF is that :D). Even if they use git, creating different remote is non trivial, as is setting this repo as default push destination for all branches. 

zf tool should be able to download the skeleton app WITHOUT git installed, IMO. Default worflow I'D expect like:

1) download  this phar

2) put it in the path

creating project:

1) cd /var/my/project/

2) zf.phar create

3) zf.phar install ZfcUser

Who dont like the tool can use git clone as well, or download the official skeleton from ZF web. 

ZFTool should also be able to work with app module-specific stuff

zf.phar module ZfcUser clear-cache

zf.phar module ZfcUser create-user [hidden email]

Having ZFTool ONLY as module doesn't make much sense. Having the API exposed in the app does make sense though (for the module-specific stuff)

On Mon, Jun 18, 2012 at 1:35 PM, Sascha-Oliver Prolic <[hidden email]> wrote:

2012/6/18 Artur Bodera <[hidden email]>:

> On Mon, Jun 18, 2012 at 10:22 AM, Sascha-Oliver Prolic
> <[hidden email]> wrote:
>>
>> nice. let's try our current approach and compare:
>> 1) git clone git://github.com/zendframework/ZendSkeletonApplication.git
>> 2) cd ZendSkeletonApplication
>> 3) php composer.phar install
>>
>> so what i've learned. setting up a zf2 project with zend tool is
>> _more_ work, actually i need 4 commands vs. 3.
>> My conclusion. We don't need Zend Tool to create the skelleton
>> application, a simple ZF2 module is enough.
>
>
>
> That's not accurate and your example applies more to a knowledgeable
> developer than
> average zf consumer :-)
>
> 1. First of all you should _not_ clone skeleton application (for several
> reasons).
> 2. Even if you did a "flat" clone and removed .git, one still needs to
> understand git to use that.
> 3. One requires composer to do what you did here.
> 4. However --- You are still free to do just that if you please (hence -
> multiple installation methods).
>
> What we're thinking here is a lean installation and configuration tool that
> you can use to perform
> 90% of routine tasks related mostly to ZF2 architecture. For example,
> modules are zf2-specific
> gizmo and there'd be no easier way to just #zf install fooModule (and
> optionally answer a few
> interactive questions along the way). Same goes for #zf create application
> which can guide
> you through the process.
>
> It _might_ be a tad longer (from your perspective), but much easier for
> beginners.
>
> On the other hand, once you've got your app set up, git nor composer won't
> help you with
> generation of user models, modules, installation, configuration, and other
> zf2-specific tasks.
> That's where it'll come in handy.
>
>
>
>
> --
>       __
>      /.)\   <a href="tel:%2B48%20695%20600%20936" value="[phone]">[phone]
>      \(./   [hidden email]

Well I am not against ZF Tool :-) We can ship a zf-tool.phar that
setups zf2 app + selfinstalls itself as module, so both win :-)

Best Regards

Sascha

--
Sascha-Oliver Prolic

[Andreas Möller]

> Obvious problem with the git-clone workflow is that not everyone is skilled enough to set up git (it's not trivial on Windows - you have to choose openssl vs peagant, etc - many devs have no idea WTF is that :D). Even if they use git, creating different remote is non trivial, as is setting this repo as default push destination for all branches.

Surely, there are probably a lot of people who have got problems setting up a WAMP or LAMP stack, but I believe this is as much out of the scope of ZF Tool as using some kind of version control - even though most of us will agree that hardly any work should be done without it.

> zf tool should be able to download the skeleton app WITHOUT git installed, IMO. Default worflow I'D expect like:
>
> 1) download  this phar
> 2) put it in the path
>
> creating project:
> 1) cd /var/my/project/
> 2) zf.phar create
> 3) zf.phar install ZfcUser
>
> Who dont like the tool can use git clone as well, or download the official skeleton from ZF web.

I think ZF Tool should *set up* a skeleton of the app, and the information required for it should reside wherever ZF Tool is installed to. However, I'd appreciate it if it were easy to modify this, so ZF Tool can actually become useful.


Andreas

[Wil Moore III]

it's not trivial on Windows

This is no longer true: http://windows.github.com/ 

[Artur Bodera]

On Mon, Jun 18, 2012 at 7:37 PM, Wil Moore III <[hidden email]> wrote:

it's not trivial on Windows

This is no longer true: http://windows.github.com/ 

It's a GUI you can click on, not a shell solution (doesn't install openssh etc.)

... and it kinda generally sucks, so it's still true :-)

Keep the comments flowing...

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

[Wil Moore III]

... and it kinda generally sucks, so it's still true :-)

I've not tried it, but I've heard generally good things until your comment. Of course, that all needs to be taken with the grain of salt. Either way, yours is still a fair point about it being a GUI tool.

[Tomáš Fejfar]

Will, it's great when your workflow is fork -> clone -> commit -> add pullrequest, but I guess (not tested yet - but based on Mac version) that it doesn't support any advanced git stuff (staging, more remotes, stash, rebasing, ....)

On Mon, Jun 18, 2012 at 8:14 PM, Wil Moore III <[hidden email]> wrote:

... and it kinda generally sucks, so it's still true :-)

I've not tried it, but I've heard generally good things until your comment. Of course, that all needs to be taken with the grain of salt. Either way, yours is still a fair point about it being a GUI tool.

[Wil Moore III]

Windows GitHub client comes with a command line shell that gives you all the fun of the cli.

Hey…that's good to know Gary. Thanks. I guess that's why I've been hearing nothing but good things. If I had to use windows, sounds like something I'd be happy to use :)

[Tomáš Fejfar]

Sure. If it includes CLI, that's great! (but that still means non-advanced user won't be able to add their own remotes when cloning the skeleton via git)

On Mon, Jun 18, 2012 at 10:23 PM, Wil Moore III <[hidden email]> wrote:

Windows GitHub client comes with a command line shell that gives you all the fun of the cli.

Hey…that's good to know Gary. Thanks. I guess that's why I've been hearing nothing but good things. If I had to use windows, sounds like something I'd be happy to use :)

[Artur Bodera]

On Mon, Jun 18, 2012 at 10:30 PM, Tomáš Fejfar <[hidden email]> wrote:

Sure. If it includes CLI, that's great! (but that still means non-advanced user won't be able to add their own remotes when cloning the skeleton via git)

On Mon, Jun 18, 2012 at 10:23 PM, Wil Moore III <[hidden email]> wrote:

Windows GitHub client comes with a command line shell that gives you all the fun of the cli.

Hey…that's good to know Gary. Thanks. I guess that's why I've been hearing nothing but good things. If I had to use windows, sounds like something I'd be happy to use :)

Can we get on topic again ?

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

[Tomáš Fejfar]

It was not entirely offtopic - the problem was whether cloning via git is a good way of setup the app or whether the ZFTool should do it... and I still thing that cloning zend`s repo will be a bad way of handling things ==> ZFTool should be able to do that ==> ZFTool should not be only a module => we¨re back on topic ;]

On Tue, Jun 19, 2012 at 11:07 AM, Artur Bodera <[hidden email]> wrote:

On Mon, Jun 18, 2012 at 10:30 PM, Tomáš Fejfar <[hidden email]> wrote:

Sure. If it includes CLI, that's great! (but that still means non-advanced user won't be able to add their own remotes when cloning the skeleton via git)

On Mon, Jun 18, 2012 at 10:23 PM, Wil Moore III <[hidden email]> wrote:

Windows GitHub client comes with a command line shell that gives you all the fun of the cli.

Hey…that's good to know Gary. Thanks. I guess that's why I've been hearing nothing but good things. If I had to use windows, sounds like something I'd be happy to use :)

Can we get on topic again ?

-- 
      __
     /.)\   <a href="tel:%2B48%20695%20600%20936" value="[phone]" target="_blank">[phone]
     \(./   [hidden email]