Stop calling things "local", start calling them "workspace"

[danepowell]

Is your feature request related to a problem? Please describe.
BLT has always had the concept of "local" environments, such as your LAMP stack, Drupal VM, Lando, whatever. This sort of crashes now that we have Cloud IDEs, which are definitely not local (semantically), but fulfill the same use case as a local environment.

Describe the solution you'd like
Rename "local" to something more meaningful, such as "workspace", to reflect the usage / intent of the environment (which is what we really care about), rather than the physical location (which is largely meaningless in any functional sense).

Specifically, the most important part of this is probably renaming isLocal() to isWorkspace() in the environment detector. And then various config file names as well.

Describe alternatives you've considered
Overloading local to include Cloud IDEs (yuck).

Additional context
Hopefully this is a 1:1 replacement, I'll need to confirm that we are actually using isLocal() in this sense throughout the codebase, and we'll need to change it in the upstream environment detector as well. Assuming it's 1:1 we can keep isLocal() as a deprecated alias for isWorkspace(). But need to ensure overall backwards compatibility.

[danepowell]

Also if we're going to have isWorkspaceEnv(), have isDeployedEnv() as well as a counterpart, implying that an environment runs a build artifact and is a shared/common environment as opposed to a scratch space running from source.

So dev/stage/prod would be "deployed", drupalvm/lando/lamp/cloud ides would be "workspace".

And document the heck out of these definitions in the environment detector.

[pavlosdan]

Just a thought that Workspace may confuse people with Drupal's "Workspaces": https://www.drupal.org/node/2968491

[pavlosdan]

If we are looking for an alternative what about "Workstation"? I don't think it has any related term within Drupal right now and can refer to both local and remote workstations, be that a local VM or a remote IDE instance.

[b-sharpe]

I'm not sure this makes sense unless Drupal also makes a similar change... local settings, local services, etc. I'd be more in favor of treating cloud envs like another remote, since well, they're remote. Is there any downfall of this just being added as if it were another remote env (i.e. dev/test/prod)? Wouldn't that allow both local and cloud simultaneously with no changes?

Also, I'd be concerned with other things "local" when actually NOT using the cloud (which will be the majority for now). For example, would local.project.com become workspace.project.com?

[danepowell]

Also, I'd be concerned with other things "local" when actually NOT using the cloud

I can see how that would be confusing, however BLT would like to be out of the business of managing local development environments, so I don't think that particular example of the URL would come up. I can't see anywhere in BLT's codebase where swapping "local" for "workspace" (or some other non-overloaded term) would look so weird.

I don't think we have to wait for Drupal core to catch up on this convention, but we should be mindful about how this might cause confusion at the intersection with core concepts like local.settings.php.

[crasx]

I may be way overthinking this but why do we need to call it anything? I landed on this thread while looking to run BLT in a prod setup for a personal site. Currently BLT does a great job of splitting out some of the things we commonly override like files, error display, and config overrides. However if I want to change or extend any of these settings I need to create the includes.settings.php file which includes another settings file which would have my config.
What if instead of (or in addition to) an EnvironmentDetector class we create an Environment class which has functions that correlate to the drupal settings we commonly change. For example functions might be Environment::getPublicFilesDirectory() or Environment::getDbSettings(). From here we can naturally begin to create abstract classes that implement best practices (eg: DevEnvironment::getLogLevel()). This would remove some coupling to the Acquia platform which has other considerations.
Shrug, just a thought. Either way I am happy BLT takes a lot of the leg work out of project setup!

[danepowell]

It occurs to me that there's actually multiple definitions / usages of "local".

In the sense that Drupal core uses it, "local" generally means "current/active, as opposed to default". For instance, local.settings.php can be interpreted as "settings that should be overridden in the local (current) environment". In this case "local" doesn't denote physical place, it might very well be that the environment is a production environment with "local" overrides.

But in the sense that developers use it, "local" generally means "on my local machine, as opposed to a Cloud environment".

So I don't think there's a problem with BLT breaking from core on this, as long as we are only renaming the latter usage of the word. And really the whole point of this exercise is to differentiate environments along a third definition, which is "is the current environment a scratch / mutable / working" environment, which is most important when considering whether it's running from a source checkout or build artifact.

I guess we should enumerate specific usages / problem cases within BLT, and consider each one individually for this.

[danepowell]

I'm going to close this for now since we haven't been able to come to consensus, and it's not clear to me that the benefits here outweigh the potential disruption.

[ctrladel]

This deserves to be reopened. It's been 3 years and this is still causing confusion for my clients around why Cloud IDE and the ddev local behave differently. The Acquia website calls Cloud IDE a development environment and BLT needs to treat it as such instead of leaving it in limbo because we can't figure out semantics.