Use drush in documentation pages

Created on 1 December 2023, 12 months ago
Updated 4 December 2023, 12 months ago

Problem/Motivation

In recommended development environments such as DDEV and Lando, you can use drush out of the box, with their prefixes ddev drush or lando drush.

On for example a Linux server, you can add ./vendor/bin to the $PATH, as described in step 2 on https://www.drush.org/latest/install/ and then use drush.

In some rare cases, it might not be possible to do this. The question is, if we should use drush or vendor/bin/drush in the documentation pages.

Proposed resolution

Since there are quite a few variants, such as ddev drush, lando drush, vendor/bin/drush, etc. -- it makes sense to use drush for simplicity, and letting the user decide which one works well for them, and add a separate Drush > Cannot use simply drush? section, to document an alternative for the exceptions where this is not possible.

Remaining tasks

User interface changes

API changes

Data model changes

📌 Task
Status

Active

Component

Correction/Clarification

Created by

🇩🇰Denmark ressa Copenhagen

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @ressa
  • 🇩🇰Denmark ressa Copenhagen
  • 🇩🇰Denmark ressa Copenhagen
  • 🇷🇺Russia xandeadx

    Newbie developers (for which documentation has been written) do not use complicated dev environment like docker, ddev, etc. They install composer, drupal, drush and want to start development. vendor/bin/drush is native, independent of OS, works for everyone method to execute drush. Advanced developers can use any method for execute drush - drush, d, sudo drush, php vendor/drush/drush/drush.

  • 🇩🇰Denmark ressa Copenhagen

    Thanks for sharing your point of view @xandeadx. There was a long discussion in Recommend DDEV as the default Drupal local development environment Active and it was decided to recommend using DDEV as local development environment, since there are issues with all the other solutions, which are not Docker-based. This recommendation is for everyone, both new users and experienced developers.

    See also the warning message at the top of the https://www.drupal.org/docs/develop/local-server-setup page:

    The recommended development environment for both macOS, Linux, and Windows is a Docker-based solution such as DDEV or Lando instead of setting up a local server manually.

    I am curious which development environment you are using?

  • 🇩🇰Denmark ressa Copenhagen

    By the way, did you see that I created this issue? It could solve this challenge, if it's possible.

  • 🇳🇿New Zealand siramsay

    I agree. I use a local Mac environment and am happy with vendor/bin/drush

    If you want to user drush you can use drush launcher https://github.com/drush-ops/drush-launcher

    Using docker isn't needed and add another hurdle. This recommendation should not be highlighted in this way.

  • 🇩🇰Denmark ressa Copenhagen

    Thanks for weighing in @siramsay, but there has been a discussion about which development environment to recommend, and a decision has been made by the community, please see Recommend DDEV as the default Drupal local development environment Active .

    Drush Launcher has been deprecated, and is no longer supported: "This repository has been archived by the owner on Aug 19, 2023. It is now read-only."

    @weitzman (Drush maintainer):
    IMO this project has lived its useful life and should be archived. In its place we promote the alternatives listed in the README.

    From Archive this project? #105

    Also, vendor/bin/drush doesn't work in DDEV.

    I have added some more suggestions under "Proposed resolution".

  • 🇫🇷France O'Briat Nantes

    Even if DDEV is the recommended env, drush is also used on "non-dev" environnements, so, IMHO, drush alone should be used in the documentation. All the details should be grouped on the drush documentation page, with it's location, the default way to run it (./vendor/bin/drush), the way to add it the $PATH, to create alias or to use those from common dev tools such as DDEV.

    An additional solution should be to use a link+code like this drush when possible.

  • 🇳🇴Norway hansfn

    I also think drush alone should be used in the documentation - both for simplicity and generality.

    And, if you are not in the root of the project, vendor/bin/drush doesn't work.

    PS! We have the same "problem" with the composer command - you need to read the instructions to get it to work. Even with DDEV you need to read, to know that you have to use ddev drush.

  • 🇫🇷France O'Briat Nantes

    It's a shame drush-launcher is no more supported.

    Maybe bash function can be provided ?

    Here's a suggestion:

    drush() {
      cur_path=$(pwd)
      while [[ "$cur_path" != "" && ! -e "$cur_path/vendor/bin/drush" ]]; do
        cur_path="${cur_path%/*}"
      done
    
      if [ -e "$cur_path/vendor/bin/drush" ]; then
        eval "$cur_path/vendor/bin/drush $@"
      else
        echo "Could no found drush, maybe your not in a drupal folder or drush is not installed. See https://www.drupal.org/docs/develop/development-tools/drush"
      fi
    }
    
  • 🇳🇴Norway hansfn

    See Drush issue. If your suggestion isn't already there, please repost. We should fix this upstream.

  • 🇫🇷France O'Briat Nantes

    @hansfn, I miss the issue, I added a comment, thanks.

    The only advantage of my proposal is that it's not based on git so it could be used on production server where git could not be available.

  • 🇩🇰Denmark ressa Copenhagen

    Thanks @O'Briat it's great with a function which does not require Git. I am removing alias as an option from the issue summary, since @greg-1-anderson clarified that the Drush folder needs to be registered in $PATH.

Production build 0.71.5 2024