Well of course it works if you also install Symfony Console. But what if the framework already has a different command line api stack? There are also some nice added benefits for abstracting the CLI out, like say running a server on a socket that talks to multiple clients where each socket is represented as a CLI interface implementation
On Thu, Jul 7, 2016 at 11:20 AM, Andrew Carter <andrewcarter1...@gmail.com> wrote: > It* is* possible to use Doctrine migrations with frameworks that don't > use Symfony Console? You just install Symfony Console like you would any > other dependency of Doctrine Migrations. > > Other than disk space, what's the problem with one dependency using one > console helper and another dependency using another? Composer vendor > binaries allow you to integrate commands from different vendors into > applications just the same. > > HTTP messages and CLI interfaces are different. HTTP messages are > something you want to pass between different third party libraries and your > application. The only benefit of doing this for CLI interfaces is that you > could add multiple commands from different vendors to the same executable - > and I don't think this is significant (not necessarily even desirable). > > On Thursday, July 7, 2016 at 9:56:27 AM UTC+1, Dracony wrote: >> >> 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 <andrewca...@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+u...@googlegroups.com. >>> To post to this group, send email to php...@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 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/40b460ed-fb4e-4460-b416-2607076a99b5%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/40b460ed-fb4e-4460-b416-2607076a99b5%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/CANamvv2ocGvP0vHvcMhpkz%3DqCh-f3%3DscAQUnXcRAqGG80aCKiw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
