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
We've discussed the drush 9 alias problem already a bit in slack, and I've reported consolidation/site-alias#38
Turns out that at least part of what I said was wrong, using an alias without location still works. What's completely broken however is site names that contain a ".", drush9 gets horribly confused over those, it still reports them with drush sa, but they don't work at all, neither with the location or without.
So maybe it would make sense to validate the proposed site name when generating aliases and not allowing to use it?
Second, currently drush 8 and 9 aliases are put in .drush/site-aliases. And even though site aliases without a "." work as @site.env, it's pretty confusing to not have them listed like that IMHO. I'm not quite sure what's going to happen with my issue and the location handling now, but I think it's fairly safe to assume that the special-handling of the sites folder will remain, so possibly drush9 aliases could be put in $HOME/.drush/sites or alternatively directly in $HOME/.drush (which at at least my config already supported, not sure if I set that up myself or if https://github.com/platformsh/platformsh-cli/blob/b61993a02acb63029e1a6bc7426d0cd3be01c5a6/src/Command/Local/LocalDrushAliasesCommand.php#L180 adds both locations.
Would be a bit awkward probably with the current legacy file location and moving it..
The text was updated successfully, but these errors were encountered:
We've discussed the drush 9 alias problem already a bit in slack, and I've reported consolidation/site-alias#38
Turns out that at least part of what I said was wrong, using an alias without location still works. What's completely broken however is site names that contain a ".", drush9 gets horribly confused over those, it still reports them with drush sa, but they don't work at all, neither with the location or without.
So maybe it would make sense to validate the proposed site name when generating aliases and not allowing to use it?
Second, currently drush 8 and 9 aliases are put in .drush/site-aliases. And even though site aliases without a "." work as @site.env, it's pretty confusing to not have them listed like that IMHO. I'm not quite sure what's going to happen with my issue and the location handling now, but I think it's fairly safe to assume that the special-handling of the sites folder will remain, so possibly drush9 aliases could be put in $HOME/.drush/sites or alternatively directly in $HOME/.drush (which at at least my config already supported, not sure if I set that up myself or if https://github.com/platformsh/platformsh-cli/blob/b61993a02acb63029e1a6bc7426d0cd3be01c5a6/src/Command/Local/LocalDrushAliasesCommand.php#L180 adds both locations.
Would be a bit awkward probably with the current legacy file location and moving it..
The text was updated successfully, but these errors were encountered: