Missing information about the version of the project going to be installed

+1 to the proposed resolutions.

I have had a vision for a pre-or-post confirmation in the works, it would need some effort to get it implemented, and we'd need to know what's possible from Package Manager in order to display the confirmation, ex.g. It also may not be possible until half-way through the process before PM re-applies to the site.

I have had a vision for a pre-or-post confirmation in the works, it would need some effort to get it implemented, and we'd need to know what's possible from Package Manager in order to display the confirmation

There seems to be two ways to tackle this:

Hmm this sounds like we want a human-readable version of the output from composer require drupal/whatever --dry-run

e.g. if I run this on 11.1.x:

composer require drupal/project_browser --dry-run
./composer.json has been updated
Running composer update drupal/project_browser
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking drupal/project_browser (1.0.0-beta6)
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing drupal/project_browser (1.0.0-beta6)
92 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found.
Using version ^1.0@beta for drupal/project_browser

I can't find an API method for this in package_manager, but it looks like one could be created out of StageBase::require() adding a --dry-run and skipping all the staging logic.

This would allow the version to be shown in any context in project_browser without having to create a staging directory first.

Related to this, does project_browser/package_manager respect a minimum stabiility flag? Ideally we'd make this configurable, default to stable releases only, then give people options if they try to install a release that doesn't have a compatible stable release.

Related to this, does project_browser/package_manager respect a minimum stabiility flag?

Yes, PM does the equivalent of `composer require drupal/some_project` so that's why we don't really know what package will be installed, because it specifically depends on Minimum Stability.

What is the minimum-stability set to in drupal/recommended-project? In institutional settings, I imagine a power user would set minimum-stability to their comfort level and users using PB would just click install, not caring about module versions. That's very much in our user world - I would be reticent to add more additional info to cards, and would be more inclined to support pre-or-post messaging to the user per ✨ Add confirmation page when installing module Active or ✨ Show users what's changed on confirmation screen Active .

A pre-or-post confirmation screen also may relate to ✨ Create a way to accept recipe input when applying one with Project Browser Active .

@chrisfromredfin asked me to reply to #5.

From Package Manager's perspective, we could pass a --dry-run flag to composer require. The problem is that the output isn't really human-readable (and I'm not sure if it can be made machine-readable), and if Composer doesn't leave behind any artifacts for us to parse (for example, the lock file that would result from a real run), then I'm not sure we have anything we can produce a user-facing summary from.

As for minimum-stability, Package Manager has no real opinion on that as far as I know. We just delegate to Composer. We could certainly supply stability flags to the StageBase::require() method to override whatever the minimum-stability is, same as you could do with composer require.

I imagine a power user would set minimum-stability to their comfort level and users using PB would just click install, not caring about module versions.

@chrisfromredfin - Was there some research done on this topic? From the security point of view, I do not think this will be a general practice. If we look at the Wordpress, you can see, that there is a plugin version displayed if you click on the plugin - so you are aware, what you are going to install. Modules can also have multiple branches, with some new features and/or BC breaks (so you will be affected even if minimum stability will be stable). Not saying that you can jump from security covered release to not covered. This seems to me very important that users are aware, what is going to be installed.

And Drupal CMS set minimum stability to alpha (as of now), so that is even worse: 🐛 Alpha stability flag in composer.json allows project_browser to download any alpha stabiility module Active . And we are talking about non-dev users here.

Yes this is the problem - if people install from composer templates that set minimum stability to something other than stable, which will be the case for any pre-release of a distribution like Drupal CMS (and maybe stable releases if the stability doesn't get raised before the release day), then they'll be defaulted to alpha or beta or rc without knowing about it. This might not be project browser's problem as such but the combination of the two seems very bad.

To be clear, Drupal CMS does use a permissive minimum-stability, but it also has prefer-stable engaged, which I'd hope would mitigate the possibility of weirdness to some degree. But I do agree that the wider net Drupal CMS casts around its dependencies makes things slightly less predictable.

I imagine a power user would set minimum-stability to their comfort level and users using PB would just click install, not caring about module versions.

I don't think this can be relied on.

For example Gin has never had a stable release, and it's quite likely that someone would want to install Gin with project_browser. If their minimum_stability is stable, they won't be able to do that, so they'll be searching how to install a release candidate.

Overall I think it's a good thing if there's some friction involved in that.

But assuming they figure out how to change their minimum stability globally, the next project they install could also be in permanent beta/rc and project browser will happily install it without them even realising it's not stable.

The problem is that the output isn't really human-readable (and I'm not sure if it can be made machine-readable), and if Composer doesn't leave behind any artifacts for us to parse (for example, the lock file that would result from a real run), then I'm not sure we have anything we can produce a user-facing summary from.

This makes sense.

If we got the release data from the d.o API instead (which I assume project browser actually uses), could we then cross-reference this against what the site has set for composer minimum stability?

This would also potentially pre-warn people when they're not going to be able to install the project then - not sure what the messaging looks like when project browser fails to install a project.

If we got the release data from the d.o API instead (which I assume project browser actually uses), could we then cross-reference this against what the site has set for composer minimum stability?

I think that might be doable. It'd be imperfect, since Composer is a bit of a black box, and the solving of transitive dependencies could affect what happens to higher-level dependencies, but at the very least we could probably give some kind of indication of what stability could be expected.

Yeah I think we could probably detect when something will definitely not get installed, but not when it might be possible to install but its own dependencies cause it to be not-installable, especially given some of those could be non-Drupal projects from packagist etc.

a site is only allowing stable releases

To be clear -- the site is only allowing stable releases in the absence of a stability flag to override that. Project Browser can install anything it wants regardless of the preferences in composer.json if it makes calls like $installer->require(['drupal/webform:@alpha']);.

Project Browser can install anything it wants regardless of the preferences in composer.json if it makes calls like $installer->require(['drupal/webform:@alpha']);

To do that, would it not need to know that webform:@beta didn't work first? I guess it could try with gradually decreasing levels of stability though?