Problem/Motivation

We currently have two separate initiatives underway: Automatic Updates and Project Browser.

For the former, there's already the Automatic Updates contrib module. The 1.x version of it is only for sites with codebases that are not managed with Composer: in other words, primarily for Drupal 7 sites, and also for some Drupal 8 sites that choose to not use Composer despite that limiting the available contrib modules that can be installed. Work has also begun in the 2.x branch of that module for Composer-managed sites, though this is still early (pre-alpha) code.

When the 2.x branch is sufficiently far enough long, that's what will get proposed for addition into Drupal 10 core.

However, I propose that when the module is proposed for addition to core, it should not be named automatic_updates, for 2 reasons:

  1. It's not ideal for a core module and a contrib module to have the same name. We've done this before (e.g., with the jsonapi module), but doing so confuses packages.drupal.org with respect to how to resolve drupal/MODULE_NAME_THAT_EXISTS_IN_BOTH_CORE_AND_CONTRIB.
  2. I think it's a bad name for the core module, because it will contain more functionality than just providing automatic updates. It will also support manual (click a button) updates. And it will eventually also provide the installation functionality for Project Browser. In other words, it will manage composer require operations in addition to composer update operations.

Given the above, I think a better name would be package_manager.

However, that would create a dichotomy of terminology between "Package Manager" and "Project Browser". The implication of such a naming is that you browse for projects and then for the projects that you decide you want to use on your site, Package Manager managers the installation and updates of the corresponding packages. Except that in this process, "projects" and "packages" are exactly the same thing. Well almost. Each project is a package. However the package might pull in dependencies, where each dependency is also a package, but may or may not also be a project.

I wonder if we would be better off with naming "Project Browser" something more like "Package Browser" or "Package Manager UI"? I know we have a lot of history on drupal.org behind the word "project", but the rest of the world (Composer, npm, operating systems) have settled on the word "package".

Proposed resolution

  1. Decide on package_manager as the module name that will implements automatic updates and other package management functionality in core.
  2. Decide on a name for the module that will let you visually browse for projects/packages that are on drupal.org that you might want to add to your site. My recommendation is that this name include the word "package" in it rather than "project", for consistency with the "package_manager" module.
  3. If we do the above, then also figure out where else within Drupal's UI and on drupal.org that we should replace the word "project" with "package".

Remaining tasks

Discuss the above proposal and suggest alternate options.

User interface changes

API changes

Data model changes

Comments

effulgentsia created an issue. See original summary.

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented
Related issues: +#2940731: Automatic Updates Initiative overview and roadmap, +#2940733: Site Builder Tool/Project Browser initiative
effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented
Issue summary: View changes
phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
CreditAttribution: phenaproxima at Acquia commented

For whatever my opinion is worth, I'm less concerned with the choice of terminology than I am with consistency. If we standardize on the term "package", then we should call it "package" everywhere, and module/theme should become more of a developer-facing distinction than something we publicize. Same goes for "project" -- I think that inconsistency is the enemy. But I don't have a strong opinion on package vs. project vs. $some_other_word.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
CreditAttribution: tedbow at Acquia commented
Issue tags: +Automatic Updates Initiative, +Project Browser Initiative
AaronMcHale’s picture

AaronMcHale
Primary language English
Location Edinburgh, Scotland
CreditAttribution: AaronMcHale commented

This is an interesting topic of discussion.

I agree package_manager makes sense, it accurately describes what it does: it installs or updates "things" (usually things containing code and visual assets), together these "things" are "packaged" up into "packages" and distributed through (ideally) packagist (whether that be Drupal's Packagist server, packagist.org or another source).

So, where do we go from here. Well I actually thing project_browser almost works*, maybe project_browser_ui (again though, almost*), since it's really just going to be a UI and we tend to use that _ui suffix for UI-type modules. The thing is, a package on its own isn't a module or a theme; To get from a package to a module or theme, the "thing in the package" needs to be constructed in a specific way that makes it a module or theme, we need a name for that "specific arrangement of parts" that distinguishes a module/theme from any other Composer package. Additionally, a Drupal project is more than just a package because it has a whole load of associated meta data, a page on Drupal.org, maybe even documentation on Drupal.org; That stuff is all bigger than just the "package".

Having said that, I actually think a better term than "project" is "extension". We already use the term "extension" in various places to group together the common parts of modules, themes and profiles; We sometimes call the grouping of those things "extensions". As a recognised term, I also think "extension" works well, it's something that many other systems use to describe their modules. So I would actually settle for extension_browser or extension_browser_ui.

So, hopefully you could all follow my logic there, I'm not sure if I even follow it (maybe that's just because it's been a long day), but hopefully that all makes sense :)

chrisfromredfin’s picture

chrisfromredfin
he/him/his
Primary language English
Location Portland, Maine
CreditAttribution: chrisfromredfin at Redfin Solutions, LLC commented

There is a difference, for sure, between Themes and Modules even in WordPress. This is something we noticed in terms of WordPress's UI where the place you browse for themes is different from where you browse for "plugins" (as WordPress call them).

So what I'm saying is the possibility is there for Themes to be "themes" and for modules / module bundles to be "packages" - in case that's a direction we want to go.

The other thing to consider is that Drupal "packages" might contain several "modules" (i.e. Commerce or some other things). So I support the "package" nomenclature for extensions, and "themes" for themes. (However, being able to lump all together and call them "extensions" might be a nice-to-have). The question is, does Project Browser intend to have a browse for themes (maybe someday, not quite fully decided, but its MVP version does NOT). Does Automatic Updates also intend to update themes?

AaronMcHale’s picture

AaronMcHale
Primary language English
Location Edinburgh, Scotland
CreditAttribution: AaronMcHale at The University of Edinburgh commented

So what I'm saying is the possibility is there for Themes to be "themes" and for modules / module bundles to be "packages" - in case that's a direction we want to go.

You could also say a profile is a "package" because it often contains other modules and themes, and in theory the browser could be used to find profiles. As a side note, I'd love to see the browser eventually included in the installer to supplement where you choose which profile you want to install; But that's long game. The other thing to consider is that we really just need to settle here on what the machine name will be; For example, let's say we went with "extension_browser", because all these things can be called "extensions" (and that's a term we already use sometimes), but that doesn't mean the UI needs to use that term. The machine name is really the only thing that can't easily be changed half way through the development cycle, which is why getting that right is really the key thing here. I quite like that idea of separate browsers, one for modules and a another for themes, because we probably want those interfaces to look different, with themes being much more focused on the visual side of things.

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
CreditAttribution: hestenet at Drupal Association commented

Had some outside conversations in Slack and some initiative calls as well.

To me - it would make sense for this subsystem to be the 'Extension manager' - which saves us from having to worry about the definition of project/package/module/theme/distro/install-profile/etc - and 'Automatic Updates' becomes a feature of the 'Extension manager'

As has been mentioned, this impacts the Project Browser initiative as well potentially - so we should look for alignment.

I'm not suggesting the project browser needs to be called an 'extension browser' though - because I don't think it is too far off base to think of 'Browsing Drupal projects to find extensions you want'

Just my 2 cents!

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia at Acquia commented

+1 from me on "Project Browser" being named "Extension Browser" (not saying we should rename the initiative at this time, but I like the word "Extension" to describe what's being browsed for). I'd also offer for consideration "Extension Finder" if we want to focus on the goal (to find something) rather than on what the user is doing to reach that goal (browsing), but that's a separate conversation, not really part of the scope of this issue.

In Slack, @tedbow offered the idea to have 3 modules instead of 2:

  • Package Manager or Composer Stager, which would have all of the behind-the-scenes functionality and APIs needed for Drupal to be able to securely and safely execute Composer commands (both update and require commands, as well as potentially other ones) on itself. This module could even be marked as a hidden module, since there would not be a need for a site builder to enable it directly, only via a different module that needs to use it. In other words, this module's name would only be for developers, not end users.
  • Extension Browser for being able to find and install extensions that aren't already in your codebase.
  • Automatic Updates (or some other name) for updating either core or extensions (or both), either automatically (on cron) or via a button click.

The latter 2 would depend on the 1st one, since Extension Browser would need to execute a composer require and Automatic Updates would need to execute a composer update.

Personally, I like this partitioning a lot. I like that what users would enable are named based on the corresponding feature that's useful to them, and that all of the details of Drupal executing Composer commands on itself would be nicely encapsulated in a hidden module.

What do others think?

AaronMcHale’s picture

AaronMcHale
Primary language English
Location Edinburgh, Scotland
CreditAttribution: AaronMcHale at The University of Edinburgh commented

Agree with @effulgentsia in comment #10, I like that architecture and naming.

Only thing I would say is, I prefer Package Manager over Composer Stager, don't tie it to a specific underlying technology. Not that we're intending to support anything other than Composer and Composer definitely isn't going anywhere, but it's probably better to just keep the name generic so if we do need to support more than just Composer one day in the distant future then we put the ground work in for that now.

Following on from that, and this is way off topic, but I like the idea of Package Manager abstracting Composer operations away into a Plugin, we could have something like Package Provider plugin type, and Composer would be the only one provided, but I think it gives a nice element of flexibility for, say, if an enterprise had their own internal package management solution or something like that, they could provide their own internal Package Provider plugin.

chrisfromredfin’s picture

chrisfromredfin
he/him/his
Primary language English
Location Portland, Maine
CreditAttribution: chrisfromredfin at Redfin Solutions, LLC commented

From the PB initiative perspective, I like #10 + #11's input.

dww’s picture

dww
we/he/they
CreditAttribution: dww at TEN7 commented

At #2906547: Add links to Drupal.org project pages to module listings in /admin/modules we're grappling with some similar problems.

I'm worried that having to say "(Drupal.org)? Package (home)? page" would be potentially confusing. I'd imagine that would be a page about the "package", i.e. the release notes for a specific release or something that was packaged for download.

Calling it the "Extension (home)? page" also seems a little weird. But maybe "Extension home page" is less Drupalismist than "Project page". 😉

Naming Is Hard(tm). But I'm way too much of an "insider" to be able to trust myself to think clearly about these terms.

AaronMcHale’s picture

AaronMcHale
Primary language English
Location Edinburgh, Scotland
CreditAttribution: AaronMcHale commented

Quoting myself from #2906547-37: Add links to Drupal.org project pages to module listings in /admin/modules:

Let's stick with the word "project" ("Drupal.org project page"), the term "project" refers to everything that makes up a module (D.o project page, issue queue, download bundle, etc), whereas the "packages" is specifically the code that is "packaged up" and shipped through Composer. So sticking with "project" in this context makes sense.

Regarding:

Calling it the "Extension (home)? page" also seems a little weird. But maybe "Extension home page" is less Drupalismist than "Project page". 😉

I wouldn't say "Project page" is a Drupalism, the term "project" is a well established and used one across the open source and business worlds. In my opinion, it's no more or less of a Drupalism then "extension" or "package".