Just to add a concrete example, you can integrate the f.e. Doctrine
commands into your existing console stack. You do not need to bootstrap
the Symfony console, add or add proxy commands to your CLI.
Example:
$ php myconsoleapp
My CLI Appilcation:
Commands:
init:database : Initialize the dataabase
run : etc.
benchmark : etc.
send-emails : etc.
When I want to use Doctine DBAL in my application I need to reimplement
the Symfony Console command. This PR would seem to lead the way to being
able to reuse the (f.e.) stock DBAL command.
$myApplication->addComand(new \Acme\MyCommand));
$myApplication->addComand(new \Doctrine\DBAL\Console\SchemaUpdate(...));
So for what its worth I think it is a great idea.
On Thu, Jul 07, 2016 at 02:20:30AM -0700, Andrew Carter 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: [1]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
> <[2]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 [3]vendor binaries. 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 [4]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
> [5]https://groups.google.com/d/topic/php-fig/_vEmRLcw-gE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [6]php-fig+u...@googlegroups.com.
> To post to this group, send email to [7]php...@googlegroups.com.
> To view this discussion on the web visit
>
> [8]https://groups.google.com/d/msgid/php-fig/6cc25422-7e4e-47a3-8c5a-0c3a97fa189a%40googlegroups.com.
> For more options, visit [9]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 [10]php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to [11]php-fig@googlegroups.com.
> To view this discussion on the web visit
>
> [12]https://groups.google.com/d/msgid/php-fig/40b460ed-fb4e-4460-b416-2607076a99b5%40googlegroups.com.
> For more options, visit [13]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. https://github.com/kurlltd/silex-doctrine-migrations-provider
> 2. javascript:
> 3. https://getcomposer.org/doc/articles/vendor-binaries.md
> 4. https://github.com/dbtlr/silex-doctrine-migrations
> 5. https://groups.google.com/d/topic/php-fig/_vEmRLcw-gE/unsubscribe
> 6. javascript:
> 7. javascript:
> 8.
> https://groups.google.com/d/msgid/php-fig/6cc25422-7e4e-47a3-8c5a-0c3a97fa189a%40googlegroups.com?utm_medium=email&utm_source=footer
> 9. https://groups.google.com/d/optout
> 10. mailto:php-fig+unsubscr...@googlegroups.com
> 11. mailto:php-fig@googlegroups.com
> 12.
> https://groups.google.com/d/msgid/php-fig/40b460ed-fb4e-4460-b416-2607076a99b5%40googlegroups.com?utm_medium=email&utm_source=footer
> 13. 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/20160707095541.GA4131%40dtlt410.Home.
For more options, visit https://groups.google.com/d/optout.
