Merge this into module_builder

I disagree 100% on this, for the following reasons:

1. This project was revised already: #2124139: I would like to take over the 'console' project namespace on Drupal.org
2. The module builder is a completely different approach and there is not know work for Drupal 8.x

I agree with chx. The name "console" has nothing to do with scaffolding. At "module builder" makes more sense. Nobody will ever find this module if they are searching on Google.

The module builder is a completely different approach and there is not know work for Drupal 8.x

@develCuy: just because a branch took one approach to implement the project's goal doesn't mean that all other branches have to follow the same approach w/o any refactoring. The only thing that branches should have in common is to provide a solution for the problem the module is solving. Take views for example: it has 3 official branches in contrib spanning Drupal 4.7 to Drupal 7. The version we have in Drupal 8 core is the fourth refactoring. Refactoring in new branches is totally fine. What is it on https://www.drupal.org/project/module_builder that goes against the goals of the current D8 version of console?

Let me answer this one @scor

Let me list you some goals of the Console project:

• Take advantage of Symfony Console Component.
• Take advantage of Twig Component in order to generate PHP, YML and other files.
• Take advantage of OOP and modern development practices.
• No plans to support previous versions of Drupal.

We named console because of the the Symfony Console Component.

This module is more than a generator or scaffolding tool we have commands that interact with the service container and there are more to come.

Container Debug

$ bin/console container:debug

Router Debug

$ bin/console router:debug

Router Rebuild

$ bin/console router:rebuild

Are the goals of module_builder in sync are they willing to adopt Console Component and OO ?

Thanks @jmolivas for weighing in! What you described in your comment above is not at all what's described on the project page at https://www.drupal.org/project/console. My comments above are based on the project description, which as is makes this project look unrelated to the name "console". Can you fix the project description with info from your comments? If I understand well, scaffolding is just a first example you can do with console, but there is more planned. Please make this clear on the project page.

Don't take my comments above the wrong way :) It looks like you are doing awesome work and that you are motivated, so please continue to contribute to Drupal! I just want to make sure that people like me who don't know about console or module_builder aren't confused by the project names and description. If it wasn't for Twitter, I wouldn't have found this module. I also want to avoid duplicate project and wasted efforts. Working with the community is better than working on your own.

Regarding the idea of build a console module, this sounds like you'd be competing with drush, which again wouldn't be a great thing. You seem to have great ideas, and I agree we should use symfony console, but instead of building something from scratch, why not contribute this to Drush? I know you are already aware of this pull request since you left a comment: https://github.com/drush-ops/drush/pull/88

I'm curious: what makes symfony console such a great fit for scaffholding? to me those two things are not really related unless I'm missing something.

@scor Thanks for your questions, I'll try to give a clear answer

"this sounds like you'd be competing with drush":
Not is a competition, is a complement. Each developer can choose their own tools.

"but instead of building something from scratch, why not contribute this to Drush?"
No built from scratch we use symfony/console, When Drush use the console component the contribution is automatic, Drush some day leave the island.

The console component provide a easy interaction with the CLI applications that is some pain point to any php application.

The console component is one of more used after symfony package, projects like composer use this because is an easy way to write commands and is becoming the standard way to create CLI applications.

The console provide
* helpers http://symfony.com/doc/current/components/console/helpers/index.html
* easy way to write commands http://symfony.com/doc/current/components/console/introduction.html#crea...

One of the main reasons for using this component is to open the door to new developers do not Drupalers, the community can be more big, you do not seek it? more people who can understand what is being done in drupal?

I invite you to test the project.

=)

> Take advantage of Twig Component in order to generate PHP, YML and other files.

I've already started using Symfony to generate YML .info files

> Take advantage of OOP and modern development practices.

Module builder uses OOP. There's still some elements of the procedural code, but those are slated to be refactored

> No plans to support previous versions of Drupal.

Module Builder differs here: just as Drush works for all current versions of Drupal, so does Module Builder.

Totally agree with @dmouse we are not building it from scratch we are using the Symfony Console & Twig components.

Related to your question @scor "I'm curious: what makes symfony console such a great fit for scaffholding?"

What it makes great is the component itself, Console is used to create the command and the interaction with the user ask different type of questions using the helpers provided by the Symfony console component

From there the collected data is passed as and array to a Twig template to render files PHP, YML, etc

@scor Related to the diff between what you see on the description and the actual console projects does is because the project is been changing and maturing based on user feedback and contributions.

We are working on a roadmap once we have that, next step will be update the project description.

FYI this is the last presentation I have done about the console project this may have more info than the project description
http://jmolivas.com/slides/drupalcampla2014/drupal-8-console-scaffolding...

That will be updated for upcoming events adding the roadmap and listing the new added commands.

As far as I can tell, Console doesn't detect how to build code. It looks like it has templates for all code in src/Resources/skeleton.

Are there any plans to make it detect Drupal's components, the way Module Builder does?

I've not looked yet at how to do this for plugin types, but with hooks, Module Builder learns about hooks from their documentation. This allows it to generate both core and contrib hooks, and learn about new hooks in the future without having to be patched.

Exactly @joachim this is the way console does Console doesn't detect how to build code instead Twig templates are created and then arguments are pass in order to render code.

We never think about detect Drupal's components but sound like an interesting approach.

I mean created when a new command is added, but learning from plugin definition sounds like a really interesting approach.

> learning from plugin definition

I could really use help from people more familiar with the D8 plugin system: #2086181: plugin generator.

This project is indeed competing with drush and module_builder.

Using the console component is indeed more up to par with latest standards but we better spend time on the others.

After seeing @chx's tantrum at #2391219: Stop the console project: doubles the contrib workload (and breaks it as well), there is no point to keep this issue open.

I invite everyone to read this: http://www.communitywiki.org/en/RightToFork "Right to Fork", Drupal is supposed to be a Free/Libre Open Source Software Project, since it stands on the GPL v2. Diversity is a key component of freedom. Contrib projects have the right to "duplicate" efforts or to fork, since it "guards against a single point of failure in any project". Who can assure 100% that drush and module_builder are the UNIQUE valid and RIGHT way to solve their use cases? There is no guarantee at all!

Let me add we are more than happy to contribute to other projects, but our foundations are OOP and Symfony components (console, twig, etc,) and module_builder in this case need to move to that in order for us to help contributing our code.

1. Diversity brings infinite benefits that drupal comunity precisely looking for.
2. I am honest to say that it has been very easy to know when to use drush and when the console ...
I never have crossed wires and write: drush generate:entity:content