Skip to content

Move drupal/console from a required dependency to a dev dependency #352

Closed

Description

@pfrenssen

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.

Activity

  1. jackbravo commented on Feb 15, 2018

    @jackbravo

    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.

  2. FatherShawn commented on Feb 15, 2018

    @FatherShawn

    And I noted that we should treat them similarly on the PR at #353 (comment)

  3. derhasi commented on Feb 15, 2018

    @derhasi
    Member

    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.

  4. g3r4 commented on Feb 15, 2018

    @g3r4

    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)?

  5. eliasdelatorre commented on Feb 15, 2018

    @eliasdelatorre

    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.

  6. nicolas-grekas commented on Feb 16, 2018

    @nicolas-grekas

    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.

  7. allgood2386 commented on Feb 16, 2018

    @allgood2386

    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.

  8. pfrenssen commented on Feb 20, 2018

    @pfrenssen
    CollaboratorAuthor

    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.

    @jackbravo

    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.

    @derhasi

    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.

    @eliasdelatorre

    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.

  9. 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
  10. pfrenssen commented on Feb 20, 2018

    @pfrenssen
    CollaboratorAuthor

    @eliasdelatorre

    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.

  11. jmolivas commented on Feb 20, 2018

    @jmolivas
    Contributor

    @pfrenssen We used and have clients using DrupalConsole on production servers and also using it on their CI/CD workflow.

    All this is because:

    • DrupalConsole provides commands for debugging and maintaining Drupal sites not only generators.
    • DrupalConsole provides chains commands to automate pipelines used on CI/CD workflow.
    • DrupalConsole provides site alias for remote command execution.

    Making a change like this will affect people using DrupalConsole via DrupalComposer on prod sites for
    daily site maintenance and debugging.

  12. pfrenssen commented on Feb 20, 2018

    @pfrenssen
    CollaboratorAuthor

    @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.

  13. jmolivas commented on Feb 20, 2018

    @jmolivas
    Contributor

    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.

  14. jackbravo commented on Feb 20, 2018

    @jackbravo

    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.

  15. jackbravo commented on Feb 20, 2018

    @jackbravo

    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.

  16. 11 remaining items

  17. jmolivas commented on Feb 22, 2018

    @jmolivas
    Contributor

    @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 joachimnicolas

    I briefly used it for its entity type code generator... then I wrote a better one in Drupal Code Builder :D

    Mentioning 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.

    Contribution to existing projects and trying out new ways are both valuable and can serve different purposes and lead to improvement.

  18. gnuget commented on Feb 22, 2018

    @gnuget

    not sure how I went going after to joachimnicolas with 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.

  19. pfrenssen commented on Feb 22, 2018

    @pfrenssen
    CollaboratorAuthor

    Thanks everybody for the constructive discussion.

    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.

  20. FatherShawn commented on Feb 22, 2018

    @FatherShawn

    @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.

  21. cmcintosh commented on Feb 22, 2018

    @cmcintosh

    @FatherShawn Im on slack if you wnat to discuss further

  22. pfrenssen commented on Feb 22, 2018

    @pfrenssen
    CollaboratorAuthor

    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 :)

  23. FatherShawn commented on Feb 22, 2018

    @FatherShawn

    @cmcintosh It is out of line for the following reasons:

    1. 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.
    2. 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.

  24. cmcintosh commented on Feb 22, 2018

    @cmcintosh

    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.

  25. cmcintosh commented on Feb 22, 2018

    @cmcintosh

    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.

  26. jmolivas commented on Feb 22, 2018

    @jmolivas
    Contributor

    @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.

  27. gnuget commented on Feb 22, 2018

    @gnuget

    There is no need to have a development tool on production, it is similar to having Devel turned on.

    Yup, this means that you aren't using all the features of the tool.

    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.

    This sounds good to me. Thanks!

  28. jmolivas commented on Feb 22, 2018

    @jmolivas
    Contributor

    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.

    Fair enough

  29. derhasi commented on Feb 22, 2018

    @derhasi
    Member

    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.

  30. webflo commented on Jun 26, 2018

    @webflo
    Member

    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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions