Drush 9 wants to be more integrated into your site, required by your
composer.json and living in your vendor directory. On your local machine you should consider shifting to Drush global launcher, which will live somewhere like
/usr/bin/drush and be the first hit for
drush in your PATH. Global launcher isn't Drush, it just knows how to find Drush, preferably in the
./vendor directory of your project, and only fallback to a globally installed Drush as a last resort.
To perform remote commands on Acquia, you should have the same version of Drush running remotely. Acquia has globally available Drush 8 (by default) and Drush 9 (using
drush9) but I should reiterate that it's not best practice to use different versions of Drush locally and remotely. So if you want run many remote Drush commands correctly, you should pimp your aliases to know how to connect to Acquia and find the right Drush.
Drush 8 had a --local switch which would try to ensure that global settings and aliases didn't get picked up, but this doesn't always work due to the way Drush bootstraps. Drush 9 differs in that it will be --local by default. So if you have bought into the idea that running each of your projects may be running a slightly different version of Drush (and that that's ok) then you should be working on putting your Drush aliases in the same repo.
As yet, I've still not seen a Drush 9 version of
acapi.drush.inc which contains a lot of convenience commands for working with Acquia. If you have one, please comment below. Depending on your project, this could be a problem, I use typhonius/acquia_cli so that I can write PHP scripts that do the things I need.
(As a side note, be careful if you are also using Platform.sh. The Platform.sh CLI is opinionated and thinks that aliases should be global, and will place a global
~/.drush/drush.yml that screws up the "--local by default" strategy. See this issue for more information.)
I recommend your aliases file will live inside your repo at
./drush/sites/self.site.yml. I understand there is a feature coming for BLT that generates aliases, if BLT is your jam, and I assume it will put aliases to the same location. Here is a sample site alias file for you to base yours on. Note that we always explicitly define the location of Drush 9. This allows:
drush @vm status- our local vagrant
drush @dev status- Acquia dev
drush @stg status- Acquia test/staging
drush @prod status- Acquia prod
vm: host: SOMESITE.vm options: alias-path: /var/www/drupalvm/docroot/drush local: true paths: dump-dir: ~/backups/drush.dbdumps drush-script: /var/www/drupalvm/vendor/bin/drush files: sites/default/files root: /var/www/drupalvm/docroot uri: SOMESITE.vm user: vagrant ssh: options: '-o "SendEnv PHP_IDE_CONFIG PHP_OPTIONS XDEBUG_CONFIG" -o PasswordAuthentication=no -i "~/.vagrant.d/insecure_private_key"' dev: host: SOMESITEdev.ssh.prod.acquia-sites.com options: ac-env: dev ac-realm: prod ac-site: SOMESITE paths: dump-dir: /home/SOMESITE.dev/drush.dbdumps drush-script: /var/www/html/SOMESITE.dev/vendor/bin/drush files: sites/default/files root: /var/www/html/SOMESITE.dev/docroot uri: dev.SOMESITE.com.au user: SOMESITE.dev stg: host: SOMESITEstg.ssh.prod.acquia-sites.com options: ac-env: test ac-realm: prod ac-site: SOMESITE alias-path: /var/www/drupalvm/docroot/drush local: true paths: dump-dir: /home/SOMESITE.test/drush.dbdumps drush-script: /var/www/html/SOMESITE.test/vendor/bin/drush files: sites/default/files root: /var/www/html/SOMESITE.test/docroot uri: staging.SOMESITE.com.au user: SOMESITE.test prod: host: SOMESITE.ssh.prod.acquia-sites.com options: ac-env: prod ac-realm: prod ac-site: SOMESITE alias-path: /var/www/drupalvm/docroot/drush local: true paths: dump-dir: /home/SOMESITE.prod/drush.dbdumps drush-script: /var/www/html/SOMESITE.prod/vendor/bin/drush files: sites/default/files root: /var/www/html/SOMESITE.prod/docroot uri: prod.SOMESITE.com.au user: SOMESITE.prod