Problem/Motivation
There are some cases where we would like people to be able to use Package Manager in a more permissive way than it currently allows. For the purposes of this issue, consider the use case of a simple local development setup (i.e., php -S) of Drupal CMS, being used by a marketer who is not technical and cannot be expected to ever look at a command line.
Package Manager requires Composer and rsync. Currently, those must be detectable in the PATH environment variable, or anything built on Package Manager will crap out with a nasty error. You can configure the paths to these executables in config, but you have to know how to do that (spoiler: it involves the command line, so we've already lost our theoretical non-technical user). That's being improved over in #3463662: When it is installed, Package Manager should try to detect the paths of Composer and rsync.
What if you don't have rsync, though? What if you don't even know what that is? You are completely prevented from installing modules into your site in a local environment, in which you are the only user, with Project Browser. You are, effectively, shut out of the Drupal ecosystem.
This is a mission-critical problem for Drupal CMS.
Proposed resolution
Let me begin by saying that Package Manager's default behavior will continue to be as it is now: sandbox everything.
But we will introduce two things here:
- A new setting,
package_manager_allow_direct_write. FALSE by default. This needs to be true for Package Manager to allow any StageBase subclass to operate on the live site directly. - A new attribute,
#[Drupal\package_manager\Attribute\AllowDirectWrite](no arguments), which a StageBase implementer can add to their StageBase subclass to signal Package Manager that, if the global setting is enabled, this stage is allowed to operate directly on the live site.
This means that Project Browser's StageBase subclass could declare that it is willing to operate on the un-sandboxed code base -- which makes sense for Project Browser, given its purpose and design -- but Automatic Updates could continue to be stringent, which makes more sense for it given its purposes and design.
API changes
A new setting and attribute. See above, or change record: https://www.drupal.org/node/3506770
Data model changes
None.
Release notes snippet
Not needed. Package Manager is alpha experimental.