What do you want ZF2 tool to be?

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

EvanDotPro
Hi Artur,


On Sun, Jun 17, 2012 at 7:42 AM, Artur Bodera <[hidden email]> wrote:
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/ ?


A while back, Matthew dropped in a ./modules directory in the root of the zf2 repository. The intention at the time was to split of the old ZF1 components into a module which would (will?) eventually serve as a compatibility layer for ZF1 apps to migrate to ZF2. Assuming we are going to keep the modules/ directory, then perhaps this is an appropriate use for it. Consider the following:

./modules/ZendTool/* - The module containing the ZF2 CLI tool

./modules/ZendTool/bin/compiler - Executable script which builds the ZendTool module into a single, self-contained executable phar for distribution. The resulting phar could be available as a stand-alone download, but would not be included in vcs.

./modules/ZendTool/bin/zf-tool - Executable script to bootstrap/run the non-phar ZendTool CLI (would also serve as the stub for the phar)

And maybe, just for the sake of discoverability, ./bin/zf-tool -- which would simply run ./modules/ZendTool/bin/zf-tool.

Why not a separate repository for a ZendTool module? Personally I feel that the ZF2 CLI should be available to me upon cloning the zf2 repository. Eventually it could possibly be split off into a separate repository, but for now I don't see much of an advantage.

---
Evan Coury, ZCE
Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Artur Bodera
On Mon, Jun 25, 2012 at 11:52 AM, Evan Coury <[hidden email]> wrote:
A while back, Matthew dropped in a ./modules directory in the root of the zf2 repository. The intention at the time was to split of the old ZF1 components into a module which would (will?) eventually serve as a compatibility layer for ZF1 apps to migrate to ZF2. Assuming we are going to keep the modules/ directory, then perhaps this is an appropriate use for it. Consider the following:

./modules/ZendTool/* - The module containing the ZF2 CLI tool

./modules/ZendTool/bin/compiler - Executable script which builds the ZendTool module into a single, self-contained executable phar for distribution. The resulting phar could be available as a stand-alone download, but would not be included in vcs.

./modules/ZendTool/bin/zf-tool - Executable script to bootstrap/run the non-phar ZendTool CLI (would also serve as the stub for the phar)

And maybe, just for the sake of discoverability, ./bin/zf-tool -- which would simply run ./modules/ZendTool/bin/zf-tool.

Why not a separate repository for a ZendTool module? Personally I feel that the ZF2 CLI should be available to me upon cloning the zf2 repository. Eventually it could possibly be split off into a separate repository, but for now I don't see much of an advantage.


Thanks for the update.

I'll do just that as it makes most sense and is quite close to the behavior from zf1.
The /bin/zf script will the self-container application running the module, which then
can install itself into userland application as a module (or just add its path to 
modules array in configuration, which is even more sane).


A.

-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Pieter Kokx
Hello,

I was just looking through the topics here, and I immediately had some idea about a tool for ZF2. Please note that I don't know too much about how ZF2 is currently build up, but I do know the basic module structure etc. Neither do I know how much there has been said about Zend\Tool on other places besides Artur's topic here.

At the basis I think it would be ideal that we have a tool that can handle the different types of ZF2 setups people have. And yet on the other hand, create and maintain applications that conform completely perfect to the recommended way of having your application.

Another part of what I would definitely want Zend\Tool to do, is integration with modules. It would be great if modules could simply hook into Zend\Tool. For examle, a Doctrine module would just put its CLI inside of Zend\Tool. Or that ZfcUser would support user creation and management via Zend\Tool (don't know if this would actually be a good use case). Note that this would be higly-application dependant.

On the other hand, you would want Zend\Tool to create a project (using the skeleton), and maybe even add composer dependencies, and even call the relevant composer commands. This would be not really dependent on the application, and basically require Zend\Tool to run without a ZF install. Concluding that I really like this usecase, I would prefer to have a .phar package of Zend\Tool. This makes application setup much, much easier.

Now you could do this by having one single .phar package, or by having two different binaries for the two groups of use cases. I would prefer to have one tool, which (depending on the current directory) provides commands for both use cases.

Just my €0.02.

Best Regards,

Pieter Kokx




On Mon, Jun 25, 2012 at 9:01 PM, Artur Bodera <[hidden email]> wrote:
On Mon, Jun 25, 2012 at 11:52 AM, Evan Coury <[hidden email]> wrote:
A while back, Matthew dropped in a ./modules directory in the root of the zf2 repository. The intention at the time was to split of the old ZF1 components into a module which would (will?) eventually serve as a compatibility layer for ZF1 apps to migrate to ZF2. Assuming we are going to keep the modules/ directory, then perhaps this is an appropriate use for it. Consider the following:

./modules/ZendTool/* - The module containing the ZF2 CLI tool

./modules/ZendTool/bin/compiler - Executable script which builds the ZendTool module into a single, self-contained executable phar for distribution. The resulting phar could be available as a stand-alone download, but would not be included in vcs.

./modules/ZendTool/bin/zf-tool - Executable script to bootstrap/run the non-phar ZendTool CLI (would also serve as the stub for the phar)

And maybe, just for the sake of discoverability, ./bin/zf-tool -- which would simply run ./modules/ZendTool/bin/zf-tool.

Why not a separate repository for a ZendTool module? Personally I feel that the ZF2 CLI should be available to me upon cloning the zf2 repository. Eventually it could possibly be split off into a separate repository, but for now I don't see much of an advantage.


Thanks for the update.

I'll do just that as it makes most sense and is quite close to the behavior from zf1.
The /bin/zf script will the self-container application running the module, which then
can install itself into userland application as a module (or just add its path to 
modules array in configuration, which is even more sane).


A.


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



Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Artur Bodera
On Tue, Jun 26, 2012 at 9:22 PM, Pieter Kokx <[hidden email]> wrote:
At the basis I think it would be ideal that we have a tool that can handle the different types of ZF2 setups people have. And yet on the other hand, create and maintain applications that conform completely perfect to the recommended way of having your application.

Yeah. Much boils down to app configuration. 

 
Another part of what I would definitely want Zend\Tool to do, is integration with modules. It would be great if modules could simply hook into Zend\Tool. For examle, a Doctrine module would just put its CLI inside of Zend\Tool. Or that ZfcUser would support user creation and management via Zend\Tool (don't know if this would actually be a good use case). Note that this would be higly-application dependant.

Once it's merged into master, you'll write your console-aware controllers in no time. All modules will be able to provide console commands. 

 
On the other hand, you would want Zend\Tool to create a project (using the skeleton), and maybe even add composer dependencies, and even call the relevant composer commands. This would be not really dependent on the application, and basically require Zend\Tool to run without a ZF install. Concluding that I really like this usecase, I would prefer to have a .phar package of Zend\Tool. This makes application setup much, much easier.

Thx for that.
 
Now you could do this by having one single .phar package, or by having two different binaries for the two groups of use cases. I would prefer to have one tool, which (depending on the current directory) provides commands for both use cases.

I prefer to have a single thing. I'm biased towards what Evan suggested - which means a separate repo with The Tool Module and a shortcut (mini-installer) inside ZendFramework/bin/



-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]


 
Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Artur Bodera
In reply to this post by Pieter Kokx
I've got very important question.

WHERE do we want to have the Skeleton ?

Currently we have a skeleton in a separate github repo. This is good, because we can have git workflow and tinker with it.
However - Zend_Tool in ZF1 was generating applications+controller+actions on the fly.


So - do we want ?

   A) Keep Skeleton repository on github - Tool will just export/clone the repo during installation.

   B) Remove the Skeleton repository -- move generation INSIDE The Tool - all app code is generated from scratch.



Thoughts?

--
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]



On Tue, Jun 26, 2012 at 9:22 PM, Pieter Kokx <[hidden email]> wrote:
Hello,

I was just looking through the topics here, and I immediately had some idea about a tool for ZF2. Please note that I don't know too much about how ZF2 is currently build up, but I do know the basic module structure etc. Neither do I know how much there has been said about Zend\Tool on other places besides Artur's topic here.

At the basis I think it would be ideal that we have a tool that can handle the different types of ZF2 setups people have. And yet on the other hand, create and maintain applications that conform completely perfect to the recommended way of having your application.

Another part of what I would definitely want Zend\Tool to do, is integration with modules. It would be great if modules could simply hook into Zend\Tool. For examle, a Doctrine module would just put its CLI inside of Zend\Tool. Or that ZfcUser would support user creation and management via Zend\Tool (don't know if this would actually be a good use case). Note that this would be higly-application dependant.

On the other hand, you would want Zend\Tool to create a project (using the skeleton), and maybe even add composer dependencies, and even call the relevant composer commands. This would be not really dependent on the application, and basically require Zend\Tool to run without a ZF install. Concluding that I really like this usecase, I would prefer to have a .phar package of Zend\Tool. This makes application setup much, much easier.

Now you could do this by having one single .phar package, or by having two different binaries for the two groups of use cases. I would prefer to have one tool, which (depending on the current directory) provides commands for both use cases.

Just my €0.02.

Best Regards,

Pieter Kokx





On Mon, Jun 25, 2012 at 9:01 PM, Artur Bodera <[hidden email]> wrote:
On Mon, Jun 25, 2012 at 11:52 AM, Evan Coury <[hidden email]> wrote:
A while back, Matthew dropped in a ./modules directory in the root of the zf2 repository. The intention at the time was to split of the old ZF1 components into a module which would (will?) eventually serve as a compatibility layer for ZF1 apps to migrate to ZF2. Assuming we are going to keep the modules/ directory, then perhaps this is an appropriate use for it. Consider the following:

./modules/ZendTool/* - The module containing the ZF2 CLI tool

./modules/ZendTool/bin/compiler - Executable script which builds the ZendTool module into a single, self-contained executable phar for distribution. The resulting phar could be available as a stand-alone download, but would not be included in vcs.

./modules/ZendTool/bin/zf-tool - Executable script to bootstrap/run the non-phar ZendTool CLI (would also serve as the stub for the phar)

And maybe, just for the sake of discoverability, ./bin/zf-tool -- which would simply run ./modules/ZendTool/bin/zf-tool.

Why not a separate repository for a ZendTool module? Personally I feel that the ZF2 CLI should be available to me upon cloning the zf2 repository. Eventually it could possibly be split off into a separate repository, but for now I don't see much of an advantage.


Thanks for the update.

I'll do just that as it makes most sense and is quite close to the behavior from zf1.
The /bin/zf script will the self-container application running the module, which then
can install itself into userland application as a module (or just add its path to 
modules array in configuration, which is even more sane).


A.


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




Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Marco Pivetta
This may be handled by composer somehow, since it should be able to decide if we want to use git or a zip (example). You should ping Seldaek on #composer or #composer-dev for that, maybe he can give you some advice. I wouldn't change the current skeleton location, but some people may want to use their own skeleton in a local network for example.


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 29 June 2012 10:47, Artur Bodera <[hidden email]> wrote:
I've got very important question.

WHERE do we want to have the Skeleton ?

Currently we have a skeleton in a separate github repo. This is good, because we can have git workflow and tinker with it.
However - Zend_Tool in ZF1 was generating applications+controller+actions on the fly.


So - do we want ?

   A) Keep Skeleton repository on github - Tool will just export/clone the repo during installation.

   B) Remove the Skeleton repository -- move generation INSIDE The Tool - all app code is generated from scratch.



Thoughts?


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



On Tue, Jun 26, 2012 at 9:22 PM, Pieter Kokx <[hidden email]> wrote:
Hello,

I was just looking through the topics here, and I immediately had some idea about a tool for ZF2. Please note that I don't know too much about how ZF2 is currently build up, but I do know the basic module structure etc. Neither do I know how much there has been said about Zend\Tool on other places besides Artur's topic here.

At the basis I think it would be ideal that we have a tool that can handle the different types of ZF2 setups people have. And yet on the other hand, create and maintain applications that conform completely perfect to the recommended way of having your application.

Another part of what I would definitely want Zend\Tool to do, is integration with modules. It would be great if modules could simply hook into Zend\Tool. For examle, a Doctrine module would just put its CLI inside of Zend\Tool. Or that ZfcUser would support user creation and management via Zend\Tool (don't know if this would actually be a good use case). Note that this would be higly-application dependant.

On the other hand, you would want Zend\Tool to create a project (using the skeleton), and maybe even add composer dependencies, and even call the relevant composer commands. This would be not really dependent on the application, and basically require Zend\Tool to run without a ZF install. Concluding that I really like this usecase, I would prefer to have a .phar package of Zend\Tool. This makes application setup much, much easier.

Now you could do this by having one single .phar package, or by having two different binaries for the two groups of use cases. I would prefer to have one tool, which (depending on the current directory) provides commands for both use cases.

Just my €0.02.

Best Regards,

Pieter Kokx





On Mon, Jun 25, 2012 at 9:01 PM, Artur Bodera <[hidden email]> wrote:
On Mon, Jun 25, 2012 at 11:52 AM, Evan Coury <[hidden email]> wrote:
A while back, Matthew dropped in a ./modules directory in the root of the zf2 repository. The intention at the time was to split of the old ZF1 components into a module which would (will?) eventually serve as a compatibility layer for ZF1 apps to migrate to ZF2. Assuming we are going to keep the modules/ directory, then perhaps this is an appropriate use for it. Consider the following:

./modules/ZendTool/* - The module containing the ZF2 CLI tool

./modules/ZendTool/bin/compiler - Executable script which builds the ZendTool module into a single, self-contained executable phar for distribution. The resulting phar could be available as a stand-alone download, but would not be included in vcs.

./modules/ZendTool/bin/zf-tool - Executable script to bootstrap/run the non-phar ZendTool CLI (would also serve as the stub for the phar)

And maybe, just for the sake of discoverability, ./bin/zf-tool -- which would simply run ./modules/ZendTool/bin/zf-tool.

Why not a separate repository for a ZendTool module? Personally I feel that the ZF2 CLI should be available to me upon cloning the zf2 repository. Eventually it could possibly be split off into a separate repository, but for now I don't see much of an advantage.


Thanks for the update.

I'll do just that as it makes most sense and is quite close to the behavior from zf1.
The /bin/zf script will the self-container application running the module, which then
can install itself into userland application as a module (or just add its path to 
modules array in configuration, which is even more sane).


A.


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





Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

David Muir-2
I was just thinking the very same thing. Having ZF-Tool be able to set up the project from a custom skeleton would be quite useful.

David

Sent from my iPhone

On 29/06/2012, at 6:53 PM, Marco Pivetta <[hidden email]> wrote:

This may be handled by composer somehow, since it should be able to decide if we want to use git or a zip (example). You should ping Seldaek on #composer or #composer-dev for that, maybe he can give you some advice. I wouldn't change the current skeleton location, but some people may want to use their own skeleton in a local network for example.


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 29 June 2012 10:47, Artur Bodera <[hidden email]> wrote:
I've got very important question.

WHERE do we want to have the Skeleton ?

Currently we have a skeleton in a separate github repo. This is good, because we can have git workflow and tinker with it.
However - Zend_Tool in ZF1 was generating applications+controller+actions on the fly.


So - do we want ?

   A) Keep Skeleton repository on github - Tool will just export/clone the repo during installation.

   B) Remove the Skeleton repository -- move generation INSIDE The Tool - all app code is generated from scratch.



Thoughts?


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



On Tue, Jun 26, 2012 at 9:22 PM, Pieter Kokx <[hidden email]> wrote:
Hello,

I was just looking through the topics here, and I immediately had some idea about a tool for ZF2. Please note that I don't know too much about how ZF2 is currently build up, but I do know the basic module structure etc. Neither do I know how much there has been said about Zend\Tool on other places besides Artur's topic here.

At the basis I think it would be ideal that we have a tool that can handle the different types of ZF2 setups people have. And yet on the other hand, create and maintain applications that conform completely perfect to the recommended way of having your application.

Another part of what I would definitely want Zend\Tool to do, is integration with modules. It would be great if modules could simply hook into Zend\Tool. For examle, a Doctrine module would just put its CLI inside of Zend\Tool. Or that ZfcUser would support user creation and management via Zend\Tool (don't know if this would actually be a good use case). Note that this would be higly-application dependant.

On the other hand, you would want Zend\Tool to create a project (using the skeleton), and maybe even add composer dependencies, and even call the relevant composer commands. This would be not really dependent on the application, and basically require Zend\Tool to run without a ZF install. Concluding that I really like this usecase, I would prefer to have a .phar package of Zend\Tool. This makes application setup much, much easier.

Now you could do this by having one single .phar package, or by having two different binaries for the two groups of use cases. I would prefer to have one tool, which (depending on the current directory) provides commands for both use cases.

Just my €0.02.

Best Regards,

Pieter Kokx





On Mon, Jun 25, 2012 at 9:01 PM, Artur Bodera <[hidden email]> wrote:
On Mon, Jun 25, 2012 at 11:52 AM, Evan Coury <[hidden email]> wrote:
A while back, Matthew dropped in a ./modules directory in the root of the zf2 repository. The intention at the time was to split of the old ZF1 components into a module which would (will?) eventually serve as a compatibility layer for ZF1 apps to migrate to ZF2. Assuming we are going to keep the modules/ directory, then perhaps this is an appropriate use for it. Consider the following:

./modules/ZendTool/* - The module containing the ZF2 CLI tool

./modules/ZendTool/bin/compiler - Executable script which builds the ZendTool module into a single, self-contained executable phar for distribution. The resulting phar could be available as a stand-alone download, but would not be included in vcs.

./modules/ZendTool/bin/zf-tool - Executable script to bootstrap/run the non-phar ZendTool CLI (would also serve as the stub for the phar)

And maybe, just for the sake of discoverability, ./bin/zf-tool -- which would simply run ./modules/ZendTool/bin/zf-tool.

Why not a separate repository for a ZendTool module? Personally I feel that the ZF2 CLI should be available to me upon cloning the zf2 repository. Eventually it could possibly be split off into a separate repository, but for now I don't see much of an advantage.


Thanks for the update.

I'll do just that as it makes most sense and is quite close to the behavior from zf1.
The /bin/zf script will the self-container application running the module, which then
can install itself into userland application as a module (or just add its path to 
modules array in configuration, which is even more sane).


A.


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





Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Marco Pivetta
@Gary: yes, but not everybody uses Git :)
Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 29 June 2012 11:30, Gary Hockin <[hidden email]> wrote:
Isn't it easier if Zend\Tool clones the github repo? Then any changes that need to be done to the skeleton app can be done in one place and won't need to wait for a full release of ZF2 or Zend\Tool to cascade.

G

Sent from my Browser


On Fri, Jun 29, 2012 at 10:11 AM, David Muir <[hidden email]> wrote:
I was just thinking the very same thing. Having ZF-Tool be able to set up the project from a custom skeleton would be quite useful.

David

Sent from my iPhone

On 29/06/2012, at 6:53 PM, Marco Pivetta <[hidden email]> wrote:

This may be handled by composer somehow, since it should be able to decide if we want to use git or a zip (example). You should ping Seldaek on #composer or #composer-dev for that, maybe he can give you some advice. I wouldn't change the current skeleton location, but some people may want to use their own skeleton in a local network for example.


Marco Pivetta

http://twitter.com/Ocramius     

http://marco-pivetta.com    



On 29 June 2012 10:47, Artur Bodera <[hidden email]> wrote:
I've got very important question.

WHERE do we want to have the Skeleton ?

Currently we have a skeleton in a separate github repo. This is good, because we can have git workflow and tinker with it.
However - Zend_Tool in ZF1 was generating applications+controller+actions on the fly.


So - do we want ?

   A) Keep Skeleton repository on github - Tool will just export/clone the repo during installation.

   B) Remove the Skeleton repository -- move generation INSIDE The Tool - all app code is generated from scratch.



Thoughts?


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



On Tue, Jun 26, 2012 at 9:22 PM, Pieter Kokx <[hidden email]> wrote:
Hello,

I was just looking through the topics here, and I immediately had some idea about a tool for ZF2. Please note that I don't know too much about how ZF2 is currently build up, but I do know the basic module structure etc. Neither do I know how much there has been said about Zend\Tool on other places besides Artur's topic here.

At the basis I think it would be ideal that we have a tool that can handle the different types of ZF2 setups people have. And yet on the other hand, create and maintain applications that conform completely perfect to the recommended way of having your application.

Another part of what I would definitely want Zend\Tool to do, is integration with modules. It would be great if modules could simply hook into Zend\Tool. For examle, a Doctrine module would just put its CLI inside of Zend\Tool. Or that ZfcUser would support user creation and management via Zend\Tool (don't know if this would actually be a good use case). Note that this would be higly-application dependant.

On the other hand, you would want Zend\Tool to create a project (using the skeleton), and maybe even add composer dependencies, and even call the relevant composer commands. This would be not really dependent on the application, and basically require Zend\Tool to run without a ZF install. Concluding that I really like this usecase, I would prefer to have a .phar package of Zend\Tool. This makes application setup much, much easier.

Now you could do this by having one single .phar package, or by having two different binaries for the two groups of use cases. I would prefer to have one tool, which (depending on the current directory) provides commands for both use cases.

Just my €0.02.

Best Regards,

Pieter Kokx





On Mon, Jun 25, 2012 at 9:01 PM, Artur Bodera <[hidden email]> wrote:
On Mon, Jun 25, 2012 at 11:52 AM, Evan Coury <[hidden email]> wrote:
A while back, Matthew dropped in a ./modules directory in the root of the zf2 repository. The intention at the time was to split of the old ZF1 components into a module which would (will?) eventually serve as a compatibility layer for ZF1 apps to migrate to ZF2. Assuming we are going to keep the modules/ directory, then perhaps this is an appropriate use for it. Consider the following:

./modules/ZendTool/* - The module containing the ZF2 CLI tool

./modules/ZendTool/bin/compiler - Executable script which builds the ZendTool module into a single, self-contained executable phar for distribution. The resulting phar could be available as a stand-alone download, but would not be included in vcs.

./modules/ZendTool/bin/zf-tool - Executable script to bootstrap/run the non-phar ZendTool CLI (would also serve as the stub for the phar)

And maybe, just for the sake of discoverability, ./bin/zf-tool -- which would simply run ./modules/ZendTool/bin/zf-tool.

Why not a separate repository for a ZendTool module? Personally I feel that the ZF2 CLI should be available to me upon cloning the zf2 repository. Eventually it could possibly be split off into a separate repository, but for now I don't see much of an advantage.


Thanks for the update.

I'll do just that as it makes most sense and is quite close to the behavior from zf1.
The /bin/zf script will the self-container application running the module, which then
can install itself into userland application as a module (or just add its path to 
modules array in configuration, which is even more sane).


A.


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







Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

akrabat
In reply to this post by Artur Bodera
HI,


I'm in favour of cloning git repo or using github ZIP file. I'd also love it if I could provide my own ZIP file location


Regards,

Rob...


On 29 Jun 2012, at 09:47, Artur Bodera wrote:

> I've got very important question.
>
> WHERE do we want to have the Skeleton ?
>
> Currently we have a skeleton in a separate github repo. This is good, because we can have git workflow and tinker with it.
> However - Zend_Tool in ZF1 was generating applications+controller+actions on the fly.
>
>
> So - do we want ?
>
>    A) Keep Skeleton repository on github - Tool will just export/clone the repo during installation.
>
>    B) Remove the Skeleton repository -- move generation INSIDE The Tool - all app code is generated from scratch.
>
>
>
> Thoughts?
>
> --
>       __
>      /.)\   +48 695 600 936
>      \(./   [hidden email]
>
>
> On Tue, Jun 26, 2012 at 9:22 PM, Pieter Kokx <[hidden email]> wrote:
> Hello,
>
> I was just looking through the topics here, and I immediately had some idea about a tool for ZF2. Please note that I don't know too much about how ZF2 is currently build up, but I do know the basic module structure etc. Neither do I know how much there has been said about Zend\Tool on other places besides Artur's topic here.
>
> At the basis I think it would be ideal that we have a tool that can handle the different types of ZF2 setups people have. And yet on the other hand, create and maintain applications that conform completely perfect to the recommended way of having your application.
>
> Another part of what I would definitely want Zend\Tool to do, is integration with modules. It would be great if modules could simply hook into Zend\Tool. For examle, a Doctrine module would just put its CLI inside of Zend\Tool. Or that ZfcUser would support user creation and management via Zend\Tool (don't know if this would actually be a good use case). Note that this would be higly-application dependant.
>
> On the other hand, you would want Zend\Tool to create a project (using the skeleton), and maybe even add composer dependencies, and even call the relevant composer commands. This would be not really dependent on the application, and basically require Zend\Tool to run without a ZF install. Concluding that I really like this usecase, I would prefer to have a .phar package of Zend\Tool. This makes application setup much, much easier.
>
> Now you could do this by having one single .phar package, or by having two different binaries for the two groups of use cases. I would prefer to have one tool, which (depending on the current directory) provides commands for both use cases.
>
> Just my €0.02.
>
> Best Regards,
>
> Pieter Kokx
>
>
>
>
>
> On Mon, Jun 25, 2012 at 9:01 PM, Artur Bodera <[hidden email]> wrote:
> On Mon, Jun 25, 2012 at 11:52 AM, Evan Coury <[hidden email]> wrote:
> A while back, Matthew dropped in a ./modules directory in the root of the zf2 repository. The intention at the time was to split of the old ZF1 components into a module which would (will?) eventually serve as a compatibility layer for ZF1 apps to migrate to ZF2. Assuming we are going to keep the modules/ directory, then perhaps this is an appropriate use for it. Consider the following:
>
> ./modules/ZendTool/* - The module containing the ZF2 CLI tool
>
> ./modules/ZendTool/bin/compiler - Executable script which builds the ZendTool module into a single, self-contained executable phar for distribution. The resulting phar could be available as a stand-alone download, but would not be included in vcs.
>
> ./modules/ZendTool/bin/zf-tool - Executable script to bootstrap/run the non-phar ZendTool CLI (would also serve as the stub for the phar)
>
> And maybe, just for the sake of discoverability, ./bin/zf-tool -- which would simply run ./modules/ZendTool/bin/zf-tool.
>
> Why not a separate repository for a ZendTool module? Personally I feel that the ZF2 CLI should be available to me upon cloning the zf2 repository. Eventually it could possibly be split off into a separate repository, but for now I don't see much of an advantage.
>
>
> Thanks for the update.
>
> I'll do just that as it makes most sense and is quite close to the behavior from zf1.
> The /bin/zf script will the self-container application running the module, which then
> can install itself into userland application as a module (or just add its path to
> modules array in configuration, which is even more sane).
>
>
> A.
>
>
> --
>       __
>      /.)\   +48 695 600 936
>      \(./   [hidden email]
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Artur Bodera
I do not understand why anyone would start off by git-cloning the Skeleton App, as config files are usually changed a lot (are variable), modules come and go, "hello world" controller will surely be deleted. I cannot imagine someone cloning skeleton app and then working on a huge corporate CMS platform, and then 6 mo later merging with the original SkeletonApplication repo (!?). 

Flat cloning (same as svn export, or zip download) is understandable - I get those sample files, delete unneeded stuff and build my first zf2 app on top of that.

Is there anything I'm missing?



On Fri, Jun 29, 2012 at 11:54 AM, Rob Allen <[hidden email]> wrote:
I'm in favour of cloning git repo or using github ZIP file. I'd also love it if I could provide my own ZIP file location

Hmm. This seems to be a popular choice.

Let me talk about downsides.

Skeleton app contains:
 - some dir structure
 - sample config
 - sample app starting point - index.php / init /bootstrapper
 - a hello world controller
 - some readme files

Downsides:
 - it's just a bunch of files
 - the Tool needs to _understand_ skeleton app in order to do mutating operations like alter config, add controller or action or module.
 - we can try to make Tool smart enough to work its way into any zf2 app, it's harder but might be desired. 
 - we could get to a point where Tool is incompatible with newest revision of Skeleton (because of some weird change).

but .... 
Custom Skeletons - ah! That's a real treat. 
I see why you picked it up. 

I'd also be able to do RAD using my own skeletons, i.e. 
    # zf create application --template=cms-app-with-acl.zip
    # zf create application --template=git://github.com/me/my-app-skeleton.git

The way I understand you guys, is that we dump the idea of ZF1 project templates (XML or similar) in favor of GIT REPOS/ZIP. That means the Tool does curl get or git clone --recursive, then works with whatever comes out (i.e. scans the dir structure).

Am I getting this right ?


-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]




 
Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

akrabat
Artur,

What you call "flat cloning" is what I meant. I had never heard that term before.

It is expected that you would never ever merge Skeleton from github after initial "flat" clone as you will have changed stuff.


Regards,

Rob..

On 29 Jun 2012, at 13:38, Artur Bodera wrote:

I do not understand why anyone would start off by git-cloning the Skeleton App, as config files are usually changed a lot (are variable), modules come and go, "hello world" controller will surely be deleted. I cannot imagine someone cloning skeleton app and then working on a huge corporate CMS platform, and then 6 mo later merging with the original SkeletonApplication repo (!?). 

Flat cloning (same as svn export, or zip download) is understandable - I get those sample files, delete unneeded stuff and build my first zf2 app on top of that.

Is there anything I'm missing?



On Fri, Jun 29, 2012 at 11:54 AM, Rob Allen <[hidden email]> wrote:
I'm in favour of cloning git repo or using github ZIP file. I'd also love it if I could provide my own ZIP file location

Hmm. This seems to be a popular choice.

Let me talk about downsides.

Skeleton app contains:
 - some dir structure
 - sample config
 - sample app starting point - index.php / init /bootstrapper
 - a hello world controller
 - some readme files

Downsides:
 - it's just a bunch of files
 - the Tool needs to _understand_ skeleton app in order to do mutating operations like alter config, add controller or action or module.
 - we can try to make Tool smart enough to work its way into any zf2 app, it's harder but might be desired. 
 - we could get to a point where Tool is incompatible with newest revision of Skeleton (because of some weird change).

but .... 
Custom Skeletons - ah! That's a real treat. 
I see why you picked it up. 

I'd also be able to do RAD using my own skeletons, i.e. 
    # zf create application --template=cms-app-with-acl.zip
    # zf create application --template=git://github.com/me/my-app-skeleton.git

The way I understand you guys, is that we dump the idea of ZF1 project templates (XML or similar) in favor of GIT REPOS/ZIP. That means the Tool does curl get or git clone --recursive, then works with whatever comes out (i.e. scans the dir structure).

Am I getting this right ?


-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]




 

Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Artur Bodera
On Fri, Jun 29, 2012 at 2:45 PM, Rob Allen <[hidden email]> wrote:
What you call "flat cloning" is what I meant. I had never heard that term before.
It is expected that you would never ever merge Skeleton from github after initial "flat" clone as you will have changed stuff.

On Fri, Jun 29, 2012 at 2:48 PM, Gary Hockin <[hidden email]> wrote:
I used the term "clone", I was wrong, I was thinking more of svn export command (if such a thing exists in Git).

Sorry for the confusion. I'm referring to a git clone option that'd be used for such operation:
--depth <depth>
Create a shallow clone with a history truncated to the specified number of revisions. 

Shallow ~= flat. Using --depth 1 is practically equal to svn export.



Rob and Gary - how about my second question? 
Are we in favor of dumping project templates (xml) a'la ZF1?
Is "zf2 app templating" (or skeleton templating) equal to unzipping or cloning a repo ? (standard skeleton or custom one) ?


-- 
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]




 
Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

duke
This post has NOT been accepted by the mailing list yet.
In reply to this post by Tomáš Fejfar
I guess we should use composer anywhere where it's possible. Composer don't require git (normal module must have correct tags for downloading source).
So ZendTools should have 3-5 command for now. Commands for:
0 check php version and compatibility of extensions (etc.)
1 get version.
2 enable/disable module in configure
3 create configured skeleton application
4 create skeleton module
Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

akrabat
In reply to this post by Artur Bodera

On 29 Jun 2012, at 15:44, Gary Hockin wrote:

> Yes, I think that it is acceptable that you need to be available to connect to Github (or other package source) in order to initialise your skeleton application; you'd have had to have been on the net to download the code in the first place.
>
> G
>
> On Fri, Jun 29, 2012 at 3:42 PM, Artur Bodera <[hidden email]> wrote:

[snip]

> Rob and Gary - how about my second question?
> Are we in favor of dumping project templates (xml) a'la ZF1?
> Is "zf2 app templating" (or skeleton templating) equal to unzipping or cloning a repo ? (standard skeleton or custom one) ?


I'm in favour of dropping the ZF1 method and would rather that the "create a new project" command grabs the code from github or a zip file. Preferably one that I can choose myself :)


Regards,

Rob...


Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Pieter Kokx
Of course, git should not be a dependency of the tool. The tool should be able to do its job without having git around. So I say we simply use github's tarball/zip delivery method for this. And it would definitely be nice if that URL is configurable.

Best Regards,

Pieter Kokx




On Fri, Jun 29, 2012 at 6:06 PM, Rob Allen <[hidden email]> wrote:

On 29 Jun 2012, at 15:44, Gary Hockin wrote:

> Yes, I think that it is acceptable that you need to be available to connect to Github (or other package source) in order to initialise your skeleton application; you'd have had to have been on the net to download the code in the first place.
>
> G
>
> On Fri, Jun 29, 2012 at 3:42 PM, Artur Bodera <[hidden email]> wrote:

[snip]

> Rob and Gary - how about my second question?
> Are we in favor of dumping project templates (xml) a'la ZF1?
> Is "zf2 app templating" (or skeleton templating) equal to unzipping or cloning a repo ? (standard skeleton or custom one) ?


I'm in favour of dropping the ZF1 method and would rather that the "create a new project" command grabs the code from github or a zip file. Preferably one that I can choose myself :)


Regards,

Rob...




Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

till
Have you guys looked at composer for this? For dependency management composer prefers zip/tar when available.

There is also "composer create-project vendor/project ..." – which gets you the code on your system.
http://getcomposer.org/doc/03-cli.md#create-project

In either case --prefer-source gets you a "checkout".

Till  

On Monday, July 2, 2012 at 6:16 PM, Pieter Kokx wrote:

> Of course, git should not be a dependency of the tool. The tool should be able to do its job without having git around. So I say we simply use github's tarball/zip delivery method for this. And it would definitely be nice if that URL is configurable.
>  
> Best Regards,
>  
> Pieter Kokx
>  
>  
>  
>  
> On Fri, Jun 29, 2012 at 6:06 PM, Rob Allen <[hidden email] (mailto:[hidden email])> wrote:
> >  
> > On 29 Jun 2012, at 15:44, Gary Hockin wrote:
> >  
> > > Yes, I think that it is acceptable that you need to be available to connect to Github (or other package source) in order to initialise your skeleton application; you'd have had to have been on the net to download the code in the first place.
> > >  
> > > G
> > >  
> > > On Fri, Jun 29, 2012 at 3:42 PM, Artur Bodera <[hidden email] (mailto:[hidden email])> wrote:
> >  
> > [snip]
> >  
> > > Rob and Gary - how about my second question?
> > > Are we in favor of dumping project templates (xml) a'la ZF1?
> > > Is "zf2 app templating" (or skeleton templating) equal to unzipping or cloning a repo ? (standard skeleton or custom one) ?
> >  
> >  
> >  
> > I'm in favour of dropping the ZF1 method and would rather that the "create a new project" command grabs the code from github or a zip file. Preferably one that I can choose myself :)
> >  
> >  
> > Regards,
> >  
> > Rob...  


Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Wil Moore III-2
> There is also "composer create-project vendor/project ..." – which gets you the code on your system.
> http://getcomposer.org/doc/03-cli.md#create-project

I like this method also. I was looking into it last night for my own skeleton projects; however, from what I could quickly tell, your skeleton project must be in packagist. Not a big deal but not as lean as simply assuming github and grabbing from there. It expects a packages.json.

Also, symphony is promoting this method to install the standard edition.

Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

till



On Monday, July 2, 2012 at 8:09 PM, Wil Moore III wrote:

> > There is also "composer create-project vendor/project ..." – which gets you the code on your system.
> > http://getcomposer.org/doc/03-cli.md#create-project
>  
>  
>  
> I like this method also. I was looking into it last night for my own skeleton projects; however, from what I could quickly tell, your skeleton project must be in packagist. Not a big deal but not as lean as simply assuming github and grabbing from there. It expects a packages.json.
>  
> Also, symphony is promoting this method to install the standard edition.  
True – must be. I haven't looked into it, but I think there's also a way to use your own composer repository for this (satis[1]). Satis is what you use for non-opensource code and to have the convenience of a require with "mycompany/mynonopensourcecode".  

So for example, this is one of my zf1 modules (till/internalapi):

./composer.phar create-project till/internalapi --repository-url=http://private.repo.url/ internalapi

Till

[1]: https://github.com/composer/satis
Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

till


On Monday, July 2, 2012 at 8:20 PM, till wrote:

>  
>  
>  
> On Monday, July 2, 2012 at 8:09 PM, Wil Moore III wrote:
>  
> > > There is also "composer create-project vendor/project ..." – which gets you the code on your system.
> > > http://getcomposer.org/doc/03-cli.md#create-project
> >  
> >  
> >  
> >  
> >  
> > I like this method also. I was looking into it last night for my own skeleton projects; however, from what I could quickly tell, your skeleton project must be in packagist. Not a big deal but not as lean as simply assuming github and grabbing from there. It expects a packages.json.
> >  
> > Also, symphony is promoting this method to install the standard edition.  
>  
> True – must be. I haven't looked into it, but I think there's also a way to use your own composer repository for this (satis[1]). Satis is what you use for non-opensource code and to have the convenience of a require with "mycompany/mynonopensourcecode".  
>  
> So for example, this is one of my zf1 modules (till/internalapi):
>  
> ./composer.phar create-project till/internalapi --repository-url=http://private.repo.url/ internalapi
[Use the force, read source.]

To add to that – it looks like you can also use a file system repo (basically a packages.json on your own machine) to describe where it finds projects.

https://github.com/composer/composer/blob/master/src/Composer/Command/CreateProjectCommand.php#L86-L102

Till
Reply | Threaded
Open this post in threaded view
|

Re: What do you want ZF2 tool to be?

Wil Moore III
> > > There is also "composer create-project vendor/project ..." – which gets you the code on your system.
> > > http://getcomposer.org/doc/03-cli.md#create-project

The following seems to work even without a packagist repo:

% cat >> $HOME/.composer/config.json <<EOF
{
  "repositories": [
      {
          "type": "package",
          "package": {
              "name": "zendframework/ZendSkeletonApplication",
              "version": "1.0.0",
              "dist": {
                  "url": "https://github.com/zendframework/ZendSkeletonApplication/zipball/master",
                  "type": "zip"
              },
              "source": {
                  "url": "git://github.com/zendframework/ZendSkeletonApplication.git",
                  "type": "git",
                  "reference": "master"
              }
          }
      }
  ]
}
EOF
 
% composer create-project zendframework/ZendSkeletonApplication --prefer-source --dev blog-app

 
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
12