Sure, actually I already did in this thread. Look at doctrine migrations provider for silex: https://github.com/kurlltd/silex-doctrine-migrations-provider If the CLI is standardized as an interface the next step would be standardizing the Command interfaces, making such glue classes unneeded, and also it would be possible to use Doctrine migrations with frameworks that don't use Symfony Command.
Basically think of the CLI and Command proposals as analogs to the HTTP message and Middlware PSRs. I see no logical reason to not create a standard interface for them On Thu, Jul 7, 2016 at 10:35 AM, Andrew Carter <andrewcarter1...@gmail.com> wrote: > I don't see this as an area where interoperability is better than > innovation, but I could be persuaded. I think the FIG has to be careful not > to standardise things for the sake of it - because it could be done - but > rather because it would be beneficial to the ecosystem to do so. > > Composer already has the option to provide vendor binaries > <https://getcomposer.org/doc/articles/vendor-binaries.md>. The only real > benefit to a PSR for this that I can see is that you could add multiple > commands from across packages to a single executable - and I ask - is that > really a significant benefit? > > If your desire is to not rely on concrete implementations, then out of the > box PHP has the capability of doing everything that you mention (stdin, > stdout, stderr, argc, argc, get_cwd(), etc...). > > Could you provide an example scenario (or scenarios) where your suggested > PSR would be beneficial to the ecosystem? > > Regards, > > Andrew > > On Thursday, July 7, 2016 at 9:16:51 AM UTC+1, Dracony wrote: >> >> Just wanted to bump this thread up, since everybody is residing in the >> Paul thread at the moment. Hopefully I can get some feedback from people >> working on CLI tools >> >> On Tuesday, June 28, 2016 at 4:31:10 PM UTC+2, Dracony wrote: >>> >>> > 1) Would it be possible to build such an interface skeleton that is >>> sufficiently generic that it doesn't end up dictating an implementation? >>> >>> Of course, we already have stream interfaces defined for PSR-7. They are >>> much more complex than what's needed for CLI though, since CLI streams are >>> either readable OR writeable. So the Stream API can be "borrowed" from >>> PSR-7 and simplified. Getting the current working directory is just a a >>> method returning a string, so there is nothing to be dictating >>> implementation there too. All in all the "interface dictating >>> implementation" problem doesn't come up at all really >>> >>> > 2) Are current CLI tool projects on board with creating a standard? >>> >>> > 3) What's the target audience, and how would it make life easier for >>> the general PHP-developing public? >>> >>> This is rather easy. Having commands coded to a common interface would >>> make packages like https://github.com/dbtlr/silex-doctrine-migrations >>> obsolete. >>> Assets management, ORM generation, running tests, etc. All these tools >>> can ship with a command adhering to the new interface and integrate into >>> frameworks without the need for bridges like these >>> >>> It'd be nice if we had Symfony representative pop up in this thread =) . >>> Since the Symfony Console API is the de-facto standard atm >>> >>> >>> >>> On Monday, June 27, 2016 at 9:57:46 AM UTC+2, Dracony wrote: >>>> >>>> A year or maybe two ago I proposed a PSR for "tasks", that would allow >>>> easier chaining of common things like e.g. migrating a database, minimizing >>>> CSS, etc. Back then it didn't really get much traction I believe because >>>> PHP world isn't really requiring as much build chains as say JS world >>>> (where gulp and Grunt plugins are abundant). >>>> >>>> So instead I wanted to rephrase it now as a Command PSR, which is >>>> basically standardizing something akin to Symfony Command, which would be >>>> really really useful, since then you wouldn't need a special service >>>> provider to get Doctrine migrations in Silex, etc. A common interface would >>>> be very simple to achieve, but it requires standardizing the CLI interface >>>> first. So let's do that! >>>> >>>> Ok, so to describe the CLI interface we need: >>>> >>>> >>>> - Input/Output streams for input, output and error >>>> - Methods to get options and arguments >>>> - Method to get current working directory >>>> >>>> Getting this PSR done will open the way for the Command PSR too, and >>>> that will be just as useful to the CLI world and Middleware PSRs are for >>>> HTTP world. >>>> >>>> What do you think? Did I catch your attention? If so, let's get >>>> cracking =) >>>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/php-fig/_vEmRLcw-gE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/6cc25422-7e4e-47a3-8c5a-0c3a97fa189a%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/6cc25422-7e4e-47a3-8c5a-0c3a97fa189a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANamvv1r%2Bmu-0komgtRNubaK8U_eSch_wjOAkOG_RY8GfSJxgQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
