Stop the console project: doubles the contrib workload (and breaks it as well)

@Chx Your comments are very appreciated!!!

I think Drupal users are very smart and I'm pretty sure they won't get confused, furthermore they appreciated diversity.

There are many projects in Open Source with the same goals but different approaches, this doesn't hurt anyone nor stops development or contributors, in Drupal there are modules that do similar things and that's OK, it's one of the open source's beauties.

Do not feel obligated to create console integrations, this project is for those who want to use it and enjoy it.
and thus there are some guys enjoying a lot working with the console because it has leveraged their Symfony skills which would be very useful for them in the near future, please do not tell them to stop something that has been so rewarding.

Greetings and thanks for following our progress, I'm a big fan of drush and I'm considering integration with the console.

Do not forget, competition will make all of us better!!!

D

@chx Why this project is a Critical Git Problem?

BTW This project only use Drupal as reference but old code is Git Hub at https://github.com/hechoendrupal/DrupalAppConsole like Drush as well https://github.com/drush-ops/drush

I will be really sad if for some kind of bullying this project is removed from Drupal.org as a project, but as @dmouse mentioned who likes will use this project even if doesn't exist in Drupal.org

I love Drush BTW I use each one time to time, in same way I love Panels and Display Suite and same way I used Overlay and Admin Menu

For me this is like saying, remove all themes and let's just leave one base theme because users will get confused, or let's remove display suite because users won't know if they should use panels or DS, even worse it's like saying lets force everyone to use only Drupal?. Diversity and innovation is what drives Open Source projects, I think the Drupal Console is a great idea and is the user is the one should decide what he would like to use it.

@chx I dont understand why you mention themes. Some analogy? Any way I believe this project create a new bridge between symfony and drupal and sounds good!

@chx I think the same way like everybody in this post, the diversity is wonderful because you can choose any module that could be easy for us, this is like "salt for taste"
The open source philosophy is about this, that you can improve one recipe o create another recipe if you want.

IMHO

Regards.

I agree 100% with Enzo. Diversity is for the better. Before CCK there was flexinode. We have panels, display suite, context, and blocks in core. We have apachesolr, search_api, xapian, custom_search, lucene, finder, search_by_page, sphinx, sphinxsearch, elasticsearch, elasticsearch_connector, search_api_elasticsearch. We have colorbox, lightbox, lightbox2, shadowbox. We have media, core file. We have bootstrap, bootstrap library. We have radix, kalatheme.

I mean, really. Eventually some of those modules merge, some don't. Some do almost the same thing, some implement the same functionality in a different way.

I think this latter case is what console is about. It is doing some of the same stuff that drush is doing, but using a more symfonyish aproach. It was born before there was a drush for drupal 8 as an experimental project. Drush could borrow some ideas from console as clearly console borrows some ideas from drush. No one is forcing module mantainers to implement both. Drush is still the defacto drupal shell. Modules will clearly integrate drush first. And I think that console tries to bring new ideas and functionality to the table, and not just doing the same thing.

I also hope that eventually the projects somehow merge. But I won't be asking this guys to close their project just because I think it will somehow confuse people.

Hi,

that deep inside of this proposal should be a bigger question. should we stop innovating? basically the diversity of different tool is what makes Drupal what it is right now, i don't think you having a different point of view than me is the problem, but please give it a second though on what you are suggesting.

thanks

I don't think the Console project should be "stopped." No one is forcing it on anyone. I for one think it's a wonderful project from what I've read about it and I am looking forward to trying it out. Open source is about sharing, diversity, contribution, giving back, and more. I don't think the theme engine analogy holds up here.

This is clearly not a critical issue. I'm also marking it "Closed (works as designed)" and will defer to the following issues instead:

• #2330769: Integrate console with drush, system wide installation - without changing core drupal
• #2298437: Merge this into module_builder

From a technical perspective, working with the maintainers of Drush and Module Builder to create a better.. module builder.. is the best way forward, this issue was not the correct approach to take.

++@DamienMcKenna
There might be some overlap, but the console maintainers were smart enough to keep the console niche and concentrate on scaffolding, which is not something that drush core does. I am sure that there will be some overlap as the console maintainers decide that they can do certain things better than drush, but beyond that, I think the confusion/overlap argument is not strong. People will use drush for whatever they use drush today, and they will use the console for scaffolding and, as @dmouse mentioned, possibly to run drush from the console.

This issue might have more validity if it was related to the console replicating module_builder functionality, but as module builder is much smaller than drush, and does not even have a 8.x version of the module yet, I would say that this is premature.

Keeping track of overlap with other established projects is good, and the console should try to collaborate with these other projects, but this issue feels political more than anything as it is doing nothing to encourage collaboration, and it will accomplish nothing as the console will be able to continue in github, and through the passion of its contributors.

This issue has no meaning, as each module maintainer was already mentioned, integrate or not their projects depending on their needs and isn't obligation for anyone to implement either or both.

Wow! i don't understand the reason for open this issue.

Like everybody (say at this moment), is like say "Let's change Panels for DS o viceversa", so what is the purpose for the open source ? , or why use Ubuntu or Linux Mint if both are distros based in Debian?, Drupal 8 it's a huge step to "get out from the drupal bubble", use more php standars and less "drupalism", and of course bring the oportunity to developers, for join to this awesome comunity.

The proyect creates confusion like all the new projects, because nobody borns knowing everything, but when used the project only depends on you, who is the best option or take advantage 2 or 3 projects, even when doing similar things, each of them have his two cents for do a better work.

I'm big fan for drush and, i really like use in all my projects, is a titanic work of the comunity for the comunity, and deserve the respect of everybody, and think that this project is equal of awesome, is the begin of the new era, when the symfony developers and the drupal developers join forces to make awesome things.

I agree with the comments made here by others. Lobbying to shut down a project simply because it's another way of doing something is, at best, Draconian. Also, I question whether it's replacing drush since it appears to provide a drush command inside it. Perhaps a better issue would be directed at finding ways to integrate this better into the drush ecosystem while still allowing it to grow in its own right... Oh wait, that exists already. :)

#2330769: Integrate console with drush, system wide installation - without changing core drupal

I don't see the confusion despite not being the brightest mind in the room.

I know what console is and what it does and I also know what Drush does and what is it purpose. I don't get what is the problem with console. Hey if they want to do it let them be, I don't see similar comments regarding the huge amount of contributed modules that replicate the same core functionality.

Some overlapping? You bet, but that doesn't mean that's bad. It's just like: "Oh really, that is also available with console? Nice!"

If this is the way to go let's create a task force with the sole purpose of pursuing those duplicated modules, for the sake of not confusing the users, heck we can even avoid adding new modules to Drupal 8, at the end if all the websites looks and behave exactly the same the final user won't be confused at all. The mere concept of accesibility will be rendered obsolete since all websites will be the same.

Ok, I extrapolated a lot, but frankly I don't get why all the fuss with console, it works for what is intended and I appreciate the effort since I'm not a symfony expert.

Thanks.

@chx, after reading #2298437: Merge this into module_builder I think I get the point. Console does duplicate some effort with module_builder and drush. So what. That didn't stop search_api (duplicating some apachesolr), or cck (duplicating some flexinode), or context, panels, display suite (duplicating some blocks). Let them try! If it is worth it, great, more people will come, if not, well, it will eventually be abandoned. There are tons of examples like this in drupal.org. We would all like that everyone could just work toghether, but sometimes people take their own iniciative and you can not tell them what to do. I would love if jmolivas and dmouse would instead be contribuiting to module_builder and drush. But this is their first contribution to drupal, and you know it is hard to dig into an already existing project, it takes time. Let them try, let them learn, let them experiment. Many people have their first commits to drupal contrib with this module and that is always something good. I'm sure something good will come out of it, wether in the ideas they propose, in code, just learning experience for them, maybe merging sometime in the future, who knows?

Best of luck dmouse, jmolivas and the rest of the people contribuiting to console!

++@DamienMcKenna

@chx, what part of contrib don't you understand? I had rather worry about your craziness... since you failed to make console merge with module_builder (#2298437: Merge this into module_builder). Man, you are a legend in the community, don't smear yourself, and accept it! the console project came to stay, patches are welcome ;)

I think @chx concerns are unwarranted. On the question of confusion, I agree with all those who are saying that diversity has always been the hallmark in Drupal, which adheres to more than one way of doing things, on the one hand, and on projects being judged, and living and dying, according to their merits.

I am surprised on this score, @chx, that you bring forward a proposal (projects may not overlap on features) which could only be implemented by putting in place a horrible bureaucracy, a bureaucracy that will decide a priori which modules may be permitted and which no. I know through all your hard work through the years for the Drupal community that you do not favor such a thing.

The second concern brought forward by @chx, is that module maintainers will have to implement both drush and console integration. Well, here again I agree with all those recognizing that this is purely voluntary, no-one is forcing anyone to write any integration code unless they feel it will enhance their modules. Unless they enjoy using the console.

But my overwhelming concern is that this is framed in negative language, i.e. "stop" this or that project, to exclude this or that project. Rather, as @jackbravo suggests, let's start a movement to integrate both console and drush, or perhaps to propose a patch to the console maintainers for integration to either be based on drush or else "just work" with drush integration, or something along those lines. Prohibitions, exclusions, etc. are unnecessary since folks will choose by using the module or not; and are dangerous, placing restrictions of the kind suggested can only work against the free community.

I think all those of us putting forward answers here would work together with you @chx on any of these positive alternatives.

Let's support everyone who works so hard to extend Drupal for the good of the community.

Victor Kane
http://awebfactory.com

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 drush in this case need to move forward to that in order for us to help contributing our code.

Talking about drush I added a comment more than 11 months ago about symfony console https://github.com/drush-ops/drush/pull/88#issuecomment-33140659 and no one reply, so what should we do, stop development as requested here or instead keep working and making this project better, and if in a future drush decide to use symfony console & twig, then at that point we will have a lot of code to contribute.

@chx Let's discuss the merits of this issue at the next DrupalCon.

Another example of mess #2703131: Modern cli command

@chx: There's a difference between "I was right, DrupalConsole sucks" and a module stuck in the middle while some pre-1.0 refactoring is going on, as is the case with Metatag's DrupalConsole integration that broke Drush. Please get over it.

@chx, this issue is closed already. I consider further posts as SPAM so turning off notifications for this issue.