Use drush in documentation pages

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.

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:

I am curious which development environment you are using?

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

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.

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

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.

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.

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
}

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

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

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.

I read the issue summary and comments and the Drush page. It seems to me that the work here is complete. There is nothing in the remaining tasks so maybe I am wrong.

What else is there to do here?

Thanks for reviving this issue @quietone.

The agreement here by the users involved in documenting Drupal is to use just drush, so it seems like there is only one remaining task, which is to update the page https://www.drupal.org/docs/updating-drupal/updating-modules-and-themes-... → which is still using vendor/bin/drush.

Or what do you think, to settle this: vendor/bin/drush or drush? :)

I think drush is fine. People can then use drush how they like, since there are many ways to set it up.

@ressa, thanks for making that clear.

I have updated https://www.drupal.org/docs/updating-drupal/updating-modules-and-themes-... → to use just 'drush' in the commands.

Thanks @siramsay and @quietone for feedback and update. I'll add the consensus reached in the Issue Summary.

Automatically closed - issue fixed for 2 weeks with no activity.