You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Move drupal/console from a required dependency to a dev dependency #352
Drupal Console has some nice functionality but it is not strictly required for drupal-project to function.
I would propose to move it from the require section to the suggest section. This means that when a Drupal project is created or updated, Composer will output a suggestion to install Drupal Console, and developers can then decide whether to use it or not depending on the needs of their project.
But the same would apply to drush right? Neither are actually needed for creating a drupal site, but people use them extensively in development. Since this is a starting point primarily for developers I like that both are enabled.
Reacted by David Valdez, Cristian Mamani, g3r4 and seidler2547
I personally see drupal/console still as a best-practice to use in a drupal development setting. As this project should be a collection of best-practices I would not strip that away. For me Drupal Console and Drush are a crucial part of Drupal development, especially when you are used to go with the CLI and therefore they should be there out of the box in my opionion.
Reacted by David Valdez, Rodrigo, Shawn Duncan, Sebastian, Cristian Mamani, g3r4, Elias De la Torre and Tipi Koivisto
I mean, if you are a professional developer that does not like to waste time, I would say it is required. I don't see the harm in including it, only benefits.
Also, Symfony comes with Symfony console as part of the project, Why shouldn't Drupal come with something similar (but more powerful)?
For the sake of consistency, both Drush and Console need to be moved to "suggestions", since none of them are strictly required for a Drupal installation.
I can see why Drush may be set as a required dependency but, frankly, the same applies to Console. Since the D8 workflow is much more complex, there's a need to have enough tools to make the initial development doable.
If this issue is about strict syntax and low level discussions, then ok, let's remove it, but we need to do the same for everything else that is not required, just like Drush.
Personally I feel that both are required if you want to do any actual work with D8.
This doesn't provide the same experience at all.
drupal-console is a requirement to the experience the authors of drupal-composer want to provide out of the box. Thus it belongs to "require". I understand that you have a different definition of what "require" means, but there is nothing anywhere that makes your definition more accurate than this definition given here: a requirement to the experience. That's a great thing.
The use case for having both tools installed by default is a far saner default then catering to the limited use case where you can't have it (presumably for infra/ATO/FEDRAMP compliance type deals).
I'd argue as a project which is providing a default code base to work from it makes sense to keep both projects in the required section. If someone needs to remove them it should be 2 trivial composer commands.
That all being said, if it is moved, both tools should be treated equally.
Everybody seems to be missing the point a bit here. Composer is a dependency management tool with very well defined sections. I'm not advocating to remove drupal-console, but to move it to the right section. Currently it is in require which is not correct, because a Drupal project does not require it to function in production. require is the section that declares the dependencies for production.
Neither are actually needed for creating a drupal site, but people use them extensively in development. Since this is a starting point primarily for developers I like that both are enabled.
I personally see drupal/console still as a best-practice to use in a drupal development setting. As this project should be a collection of best-practices I would not strip that away. For me Drupal Console and Drush are a crucial part of Drupal development, especially when you are used to go with the CLI and therefore they should be there out of the box in my opionion.
I can see why Drush may be set as a required dependency but, frankly, the same applies to Console. Since the D8 workflow is much more complex, there's a need to have enough tools to make the initial development doable.
What all of you have in common is a need is to have drupal-console on a development environment, so that you can create a drupal site and develop it: then require-dev is the place to be. Not require which is the production build.
I wanted to add it to suggest so people can decide for themselves where to put it. But require-dev is also fine for me. I personally use drupal-console for initial scaffolding at the start of the project, and after this phase I don't need it to be permanently available in my development environment. But it seems most people here think it is worthwhile to have it permanently on their dev machines.
changed the title [-]Move drupal/console from a required dependency to a suggestion[/-][+]Move drupal/console from a required dependency to a dev dependency[/+]on Feb 20, 2018
For the sake of consistency, both Drush and Console need to be moved to "suggestions", since none of them are strictly required for a Drupal installation.
We cannot move Drush to suggest since it is an actual dependency of drupal-project itself, we use it in the test suite. I proposed on the PR to move it to require-dev but @weitzman made the correct observation that a typical Drupal site requires it in the production environment.
Just because you used only for development it does not mean everyone uses it like that.
I wanted to add it to suggest so people can decide for themselves where to put it. But require-dev is also fine for me. I personally use drupal-console for initial scaffolding at the start of the project, and after this phase I don't need it to be permanently available in my development environment. But it seems most people here think it is worthwhile to have it permanently on their dev machines.
so... @weitzman (drush maintainer) made an observation that drush is used in production in any typical web site, and you assume that as correct. @jmolivas makes the same observation for drupal console, but he is a special snowflake.
Reacted by Omar Aguirre, David Valdez, Shawn Duncan and Jesus Manuel Olivas
I would be happy to add drupal-console back to the require section when the automated tests are running and the "mission-critical" commands are covered with test. What I mean with "mission-critical" are the ones that are absolutely essential for a devop to investigate a problem on production and deploy updates: clearing the cache, performing database updates, enabling / uninstalling modules etc. I don't care about tests for pure development related commands like code generation etc.
I also think that there will be very little impact for the main target audience of drupal-console (developers) if we move it to require-dev. All developers install the dev dependencies anyway, so they will have it available. Also we don't impact existing users of drupal-project - the projects are created using composer create-project which doesn't create an upstream reference back to the project. Any changes we make are not pulled back into the projects of our users. So drupal-console will not suddenly vanish from our existing users' production instances.
I don't know if you have a specific time frame in mind for adding test coverage? Maybe we can revisit it in 3 or 6 months?
I will leave this open for a few more days in case this requires some more discussion, but I think it looks we are mostly in agreement now.
@cmcintosh Your comment above was inappropriate: #352 (comment) because it does not discuss the presented issue but shifts to an ad hominem strategy or personal attack. Behaving in this way is damaging to our community. Specifically, such behavior undermines the technical discussion at hand and discourages others from contributing or speaking up for fear of being targets themselves.
Let's please keep this on topic. I know I am to blame for the emotions here since it was too harsh to propose to move drupal-console to suggest instead of require-dev. I apologise for upsetting anyone.
Let's just agree that it is difficult to communicate on the internet and people just care very deeply about their work, we're just humans! Please don't criticize people here for what they have said. Let's focus on the software :)
Reacted by gitressa, David Valdez and Johannes Haseitl
@cmcintosh It is out of line for the following reasons:
The disagreement under discussion is the technical merits of their code and the appropriate use of their code in this project. It is off topic.
Personal attacks in public damage community and individuals. Which is why it is addressed in the Drupal Code of Conduct.
@pfrenssen We need to keep this conversation on topic, agreed. But not saying something to each other when we depart from the appropriate conduct is also not correct - it gives consent to the behavior.
Did you even read the thread on twitter, or are you just jumping on a bandwagon? The thing you are accusing me of is exactly what was happening and it was in relation and referenced on this issue. I have personally been the target of such comments/attacks and is why I spoke up. There is nothing more chilling to contributing to being told, you shouldn't be working on the module you are working on because it is too similar to something else.
unfollowing this thread as it will just lead to me getting more heated and being further misunderstood. Im available in other more appropriate channels. Towards the moving of console to require-dev / suggest i think its a valid idea. There is no need to have a development tool on production, it is similar to having Devel turned on.
@cmcintosh But DrupalConsole is no longer development tool only, it is fully featured CLI that why is used in production as mentioned before you can use it to import/export config, install drupal, clear cache, debug routes, debug services. Yes, the code generation is probably the part that shines the most, but is no longer a scaffolding tool only, is a Full CLI to administer the system to automate tasks creating pipelines and execute several commands using YAML definitions.
I also think that there will be very little impact for the main target audience of drupal-console (developers) if we move it to require-dev
DrupalConsole is no longer development tool only, it is fully featured CLI that why is used in production. But will impact people using it to deploy their sites.
I would be happy to add drupal-console back to the require section when the automated tests are running and the "mission-critical" commands are covered with test.
We totally agree on this one. This is must-have for the project, and we are working on having fixed we are defining a roadmap and the ETA for this issue.
I don't know if you have a specific time frame in mind for adding test coverage? Maybe we can revisit it in 3 or 6 months?
We will keep you informed.
I will leave this open for a few more days in case this requires some more discussion, but I think it looks we are mostly in agreement now.
Thanks for getting back on the topic. I know it is sometimes hard to perceive the perspective of others, especially if they seem to be or are emotional.
On the topic: I am not sure on the next move now. I'd tend to move drupal/console to require-dev, because of my personal usage behaviour, but I also can see the valid use case of a production replacement/fallback for drush.
I think @webflo should review this for a "final" decision.
Reacted by Shawn Duncan, Jesus Manuel Olivas, David Valdez, Pieter Frenssen and Joao Ventura
Activity
jackbravo commentedon Feb 15, 2018
But the same would apply to drush right? Neither are actually needed for creating a drupal site, but people use them extensively in development. Since this is a starting point primarily for developers I like that both are enabled.
FatherShawn commentedon Feb 15, 2018
And I noted that we should treat them similarly on the PR at #353 (comment)
derhasi commentedon Feb 15, 2018
I personally see
drupal/consolestill as a best-practice to use in a drupal development setting. As this project should be a collection of best-practices I would not strip that away. For me Drupal Console and Drush are a crucial part of Drupal development, especially when you are used to go with the CLI and therefore they should be there out of the box in my opionion.g3r4 commentedon Feb 15, 2018
I mean, if you are a professional developer that does not like to waste time, I would say it is required. I don't see the harm in including it, only benefits.
Also, Symfony comes with Symfony console as part of the project, Why shouldn't Drupal come with something similar (but more powerful)?
eliasdelatorre commentedon Feb 15, 2018
For the sake of consistency, both Drush and Console need to be moved to "suggestions", since none of them are strictly required for a Drupal installation.
I can see why Drush may be set as a required dependency but, frankly, the same applies to Console. Since the D8 workflow is much more complex, there's a need to have enough tools to make the initial development doable.
If this issue is about strict syntax and low level discussions, then ok, let's remove it, but we need to do the same for everything else that is not required, just like Drush.
Personally I feel that both are required if you want to do any actual work with D8.
nicolas-grekas commentedon Feb 16, 2018
This doesn't provide the same experience at all.
drupal-console is a requirement to the experience the authors of drupal-composer want to provide out of the box. Thus it belongs to "require". I understand that you have a different definition of what "require" means, but there is nothing anywhere that makes your definition more accurate than this definition given here: a requirement to the experience. That's a great thing.
allgood2386 commentedon Feb 16, 2018
The use case for having both tools installed by default is a far saner default then catering to the limited use case where you can't have it (presumably for infra/ATO/FEDRAMP compliance type deals).
I'd argue as a project which is providing a default code base to work from it makes sense to keep both projects in the required section. If someone needs to remove them it should be 2 trivial composer commands.
That all being said, if it is moved, both tools should be treated equally.
pfrenssen commentedon Feb 20, 2018
Everybody seems to be missing the point a bit here. Composer is a dependency management tool with very well defined sections. I'm not advocating to remove drupal-console, but to move it to the right section. Currently it is in
requirewhich is not correct, because a Drupal project does not require it to function in production.requireis the section that declares the dependencies for production.@jackbravo
@derhasi
@eliasdelatorre
What all of you have in common is a need is to have drupal-console on a development environment, so that you can create a drupal site and develop it: then
require-devis the place to be. Notrequirewhich is the production build.I wanted to add it to
suggestso people can decide for themselves where to put it. Butrequire-devis also fine for me. I personally use drupal-console for initial scaffolding at the start of the project, and after this phase I don't need it to be permanently available in my development environment. But it seems most people here think it is worthwhile to have it permanently on their dev machines.[-]Move drupal/console from a required dependency to a suggestion[/-][+]Move drupal/console from a required dependency to a dev dependency[/+]pfrenssen commentedon Feb 20, 2018
@eliasdelatorre
We cannot move Drush to
suggestsince it is an actual dependency of drupal-project itself, we use it in the test suite. I proposed on the PR to move it torequire-devbut @weitzman made the correct observation that a typical Drupal site requires it in the production environment.jmolivas commentedon Feb 20, 2018
@pfrenssen We used and have clients using DrupalConsole on production servers and also using it on their CI/CD workflow.
All this is because:
Making a change like this will affect people using DrupalConsole via DrupalComposer on prod sites for
daily site maintenance and debugging.
pfrenssen commentedon Feb 20, 2018
@jmolivas yes but you are the maintainer, you are a special snowflake :) I think 80% of Drupal sites do not require it in production.
It is a heavy package with many dependencies. For maintenance reasons the production builds should be as small as possible.
jmolivas commentedon Feb 20, 2018
Just because you used only for development it does not mean everyone uses it like that.
jackbravo commentedon Feb 20, 2018
so... @weitzman (drush maintainer) made an observation that drush is used in production in any typical web site, and you assume that as correct. @jmolivas makes the same observation for drupal console, but he is a special snowflake.
jackbravo commentedon Feb 20, 2018
About drupal console being a heavy package. Both drush and console have a similar number of dependencies:
Back when both used to be released as .phar packages drush was 4.38 MB and console was 2.25 MB.
11 remaining items
jmolivas commentedon Feb 22, 2018
@cmcintosh totally out of the scope of this thread but to add some context
Interesting how you complain about my reply but said nothing about the original tweet from
joachimnicolasMentioning you wrote something better without providing a real comparative and data
I am not interested to resurrect that discussion. That thread is closed already with a great comment by NickWilde.
gnuget commentedon Feb 22, 2018
not sure how I went going after to
joachimnicolaswith my tweet.My question was honest, if his generator is better we could re-use some of that to improve the console, sorry if it sounds rude to you.
But agree that is out of the scope of what we are discussing here, you aren't helping to move forward this discussion to be honest.
pfrenssen commentedon Feb 22, 2018
Thanks everybody for the constructive discussion.
I would be happy to add drupal-console back to the
requiresection when the automated tests are running and the "mission-critical" commands are covered with test. What I mean with "mission-critical" are the ones that are absolutely essential for a devop to investigate a problem on production and deploy updates: clearing the cache, performing database updates, enabling / uninstalling modules etc. I don't care about tests for pure development related commands like code generation etc.I also think that there will be very little impact for the main target audience of drupal-console (developers) if we move it to
require-dev. All developers install the dev dependencies anyway, so they will have it available. Also we don't impact existing users of drupal-project - the projects are created usingcomposer create-projectwhich doesn't create an upstream reference back to the project. Any changes we make are not pulled back into the projects of our users. So drupal-console will not suddenly vanish from our existing users' production instances.I don't know if you have a specific time frame in mind for adding test coverage? Maybe we can revisit it in 3 or 6 months?
I will leave this open for a few more days in case this requires some more discussion, but I think it looks we are mostly in agreement now.
FatherShawn commentedon Feb 22, 2018
@cmcintosh Your comment above was inappropriate: #352 (comment) because it does not discuss the presented issue but shifts to an ad hominem strategy or personal attack. Behaving in this way is damaging to our community. Specifically, such behavior undermines the technical discussion at hand and discourages others from contributing or speaking up for fear of being targets themselves.
cmcintosh commentedon Feb 22, 2018
@FatherShawn Im on slack if you wnat to discuss further
pfrenssen commentedon Feb 22, 2018
Let's please keep this on topic. I know I am to blame for the emotions here since it was too harsh to propose to move drupal-console to
suggestinstead ofrequire-dev. I apologise for upsetting anyone.Let's just agree that it is difficult to communicate on the internet and people just care very deeply about their work, we're just humans! Please don't criticize people here for what they have said. Let's focus on the software :)
FatherShawn commentedon Feb 22, 2018
@cmcintosh It is out of line for the following reasons:
@pfrenssen We need to keep this conversation on topic, agreed. But not saying something to each other when we depart from the appropriate conduct is also not correct - it gives consent to the behavior.
cmcintosh commentedon Feb 22, 2018
Did you even read the thread on twitter, or are you just jumping on a bandwagon? The thing you are accusing me of is exactly what was happening and it was in relation and referenced on this issue. I have personally been the target of such comments/attacks and is why I spoke up. There is nothing more chilling to contributing to being told, you shouldn't be working on the module you are working on because it is too similar to something else.
cmcintosh commentedon Feb 22, 2018
unfollowing this thread as it will just lead to me getting more heated and being further misunderstood. Im available in other more appropriate channels. Towards the moving of console to require-dev / suggest i think its a valid idea. There is no need to have a development tool on production, it is similar to having Devel turned on.
jmolivas commentedon Feb 22, 2018
@cmcintosh But DrupalConsole is no longer development tool only, it is fully featured CLI that why is used in production as mentioned before you can use it to import/export config, install drupal, clear cache, debug routes, debug services. Yes, the code generation is probably the part that shines the most, but is no longer a scaffolding tool only, is a Full CLI to administer the system to automate tasks creating pipelines and execute several commands using YAML definitions.
gnuget commentedon Feb 22, 2018
Yup, this means that you aren't using all the features of the tool.
This sounds good to me. Thanks!
jmolivas commentedon Feb 22, 2018
DrupalConsole is no longer development tool only, it is fully featured CLI that why is used in production. But will impact people using it to deploy their sites.
We totally agree on this one. This is must-have for the project, and we are working on having fixed we are defining a roadmap and the ETA for this issue.
We will keep you informed.
Fair enough
derhasi commentedon Feb 22, 2018
Thanks for getting back on the topic. I know it is sometimes hard to perceive the perspective of others, especially if they seem to be or are emotional.
On the topic: I am not sure on the next move now. I'd tend to move drupal/console to require-dev, because of my personal usage behaviour, but I also can see the valid use case of a production replacement/fallback for drush.
I think @webflo should review this for a "final" decision.
webflo commentedon Jun 26, 2018
Wow, this was a heated discussion.
I will keep it as is for now. This could be a feature of the setup wizard. #384
Thank you all!