search

acquia / drupal-environment-detector

Provides common methods for detecting the current Acquia environment
GNU General Public License v2.0
10 stars 12 forks source link

Count Cloud IDE as Local #21

Open crasx opened 2 years ago

crasx commented 2 years ago

Ran into an issue with a blt project where local.settings.php was not being included. Turned out to be because isLocalEnv returns false for Acquia cloud IDE. Should this be true? Happy to throw up a PR here or I can fix it downstream in blt.

Reference call in BLT: https://github.com/acquia/blt/blob/main/settings/blt.settings.php#L132

danepowell commented 2 years ago

We cannot call IDEs local, because they are functionally much more closely aligned to Acquia Cloud (e.g. settings file locations, file directories, etc)

Previous discussion: https://github.com/acquia/blt/issues/4175

nikunjkotecha commented 2 years ago

LANDO / IDE - while they are more similar to Acquia Cloud (or Cloud Next) their purpose is to serve as development environment only. Now term local is ambiguous but that is what is used today in BLT and all other places.

I vote for considering both IDE and LANDO as local till we have conclusion and work done to remove the usage of "local" from all places.

We have to use separate plugins to make it work like https://github.com/pavlosdan/blt-ide-local as of now which doesn't make sense to me.

pavlosdan commented 2 years ago

IMO both the IDE and Lando should be considered "local" environments by the environment detector. For all intents and purposes they are used for "local" development on their respective environments regardless of their similarities to Acquia Hosting.

ba66e77 commented 2 years ago

I vote for considering both IDE and LANDO as local till we have conclusion and work done to remove the usage of "local" from all places.

Heavy plus one

mikemadison13 commented 2 years ago

I realize it's more similarly aligned with the cloud, that does make sense, but I think we still need some method of identifying that the IDE is an individual development workspace and therefore there may be some overrides that need to be git ignored and treated as a "local."

i know we've gotten very hung up on the nomenclature of local + workspace + whatever in the past, I don't want to go down that rabbit hole. But I think we need some methodology for a "local-like" behavior in the detector for IDEs.

danepowell commented 2 years ago

Yeah I don't want to get buried in semantics, but I do care about not breaking people's applications, which is what will happen if we go making IDEs local. Then all the people whose applications broke will open an issue asking us to make it non-local again, and we're back to square one.

I want to see a list of every known reference to isLocalEnv(), e.g. in BLT and Acquia CLI but also any third-party packages. Then I want to see what breaks if IDEs are considered local.

If the answer is "nothing breaks", then I'm happy to move forward with making Cloud IDE local with a strongly-worded comment to this effect on isLocalEnv().

If stuff does break, very likely we need to split up isLocalEnv() into multiple methods that are more meaningfully and intuitively named than "local", which is a relic of the past in the age of Cloud development.