Problem/Motivation

Ideally the root farmOS project composer.json file could remove the "minimum-stability": "dev" line, and fall back on the default (stable): https://getcomposer.org/doc/04-schema.md#minimum-stability

Then, it would be up to downstream maintainers of their projects to decide if they need additional non-stable dependencies, and could add that line themselves. Meanwhile farmOS could have a policy of only allowing "stable" dependencies.

Proposed resolution

We have a few dependencies right now that still require the "minimum-stability": "dev" line. Let's identify them and figure out next steps.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Comments

m.stenta created an issue. See original summary.

m.stenta’s picture

Issue tags: +beta blocker

Adding "beta blocker" tag.

m.stenta’s picture

We will be adding the Views GeoJSON module, but currently it has some commits in the dev branch that we need. See #3207257: Requesting 8.x-1.1 release

m.stenta’s picture

Issue summary: View changes

Added a list of non-stable modules we currently depend on. More than I expected... :-)

Also worth noting: farmOS itself will not be "stable" when beta is released... so maybe "beta blocker" is a little too strong for this. Needs more thought...

paul121’s picture

Issue summary: View changes

Adding link to the Gin beta roadmap issue.

m.stenta’s picture

Issue summary: View changes

views_geojson tagged a new release - cross that one off the list!

paul121’s picture

Issue summary: View changes

Adding link to IEF 8.x-1.0 roadmap.

  • m.stenta committed 2b95c64 on 2.x
    Issue #3207255: Update csv_serialization and entity_reference_integrity...
m.stenta’s picture

Issue summary: View changes

Thanks @mmjvb! Updated both and crossed them off the list! :-)

m.stenta’s picture

Issue summary: View changes

@symbioquine has a pull request open to upgrade farmOS-map to 2.0.0-alpha.0, which is likely to be merged.

Adding farmOS-map as a blocker for this issue...

m.stenta’s picture

Moving this to "stable blocker" as it does not need to block "beta".

m.stenta’s picture

Issue summary: View changes

farmOS map is stable now.

m.stenta’s picture

Priority: Normal » Minor

Quick update/thoughts:

fraction and log are both maintained by me, and I plan to tag stable releases of those. Just waiting to see if anything else bubbles up from our farmOS 2.x dev process - but I think they are pretty much ready.

entity_reference_validators and gin are both currently in alpha.

Everything else is either beta (jsonapi_schema) or rc (inline_entity_form), and I don't have high hopes that either of those will change to stable anytime soon (they have large user bases and are relatively slow moving).

So... maybe completely removing minimum-stability isn't realistic. But if we could nudge entity_reference_validators and gin to beta then we could at least set that as our minimum.

Kinda defeats the purpose of removing it entirely I guess. Downgrading this to "minor", but I'll leave the "stable blocker" tag just in case things change between now and then.

m.stenta’s picture

Issue summary: View changes

Released Log 2.0.0.

m.stenta’s picture

Issue summary: View changes

Released Fraction 2.0.0.

m.stenta’s picture

Now that Log and Fraction have stable releases, we no longer require and *-dev packages, which means we could technically change "minimum-stability": "dev" to "minimum-stability": "alpha". But if we're going to take incremental steps with this, I feel like we might as well wait for Gin and Entity Reference Validators to go from alpha to beta and change it to "minimum-stability": "beta".

m.stenta’s picture

Oh this is worth reviewing in more detail: https://www.drupal.org/node/3174472

m.stenta’s picture

Issue tags: -stable blocker

Removing the "stable blocker" tag from this. It can happen after 2.0.0. There isn't much difference either way.

mmjvb’s picture

Propose the following strategy:
With minimum-stability applying to constraints of any package of your project, suggest to keep it as stable. You don't want dev versions of just any package. So, remove minimum-stability / prefer-stable from composer.json.

Apply @RC, @beta where needed, use exact branch/tag for dev or alpha.
Move @RC, @beta upwards as soon as possible. Monitor exact branch/tag and deal with new situation.

Document these situations for dependencies of primary requirements. Those need to be added as primary requirement allowing non-stable otherwise your requirements can't be resolved.

m.stenta’s picture

Issue summary: View changes

Thanks for the suggestions @mmjvb!

Since the last update, Gin released a beta, so the only remaining alpha we're using is Entity Reference Validators. I opened an issue for that in their queue in September, but forgot to link to it from this issue's description (updated now): #3239718: 8.x-1.0 Release.

Apply @RC, @beta where needed, use exact branch/tag for dev or alpha.

Ah, does this mean that Composer won't complain about @RC/@beta, but will complain about @alpha? And the workaround is to specify the exact alpha release version? I didn't know that!

If so, then Entity Reference Validators is the only one we would need to pin. That's manageable!

Other than that, the project composer.json is currently referencing farmos/farmos: 2.x-dev, but once we release 2.0.0 (which I want to do very soon), then we can change that to ^2. So perhaps we can do all of that at the same time.

Move @RC, @beta upwards as soon as possible. Monitor exact branch/tag and deal with new situation.

Agreed - and maybe we could open a follow-up issue for that specifically. The only projects we would need to monitor are Gin (@beta), Inline Entity Form (@RC), and JSON:API Schema (@beta but currently pinned to 1.0-beta1 since we are patching it).

Feels like we're close!

m.stenta’s picture

Adding the "stable blocker" tag back again, with the above in mind. If we can do it as part of the 2.0.0 release that would be great!

m.stenta’s picture

Issue tags: +stable blocker
m.stenta’s picture

Ah, does this mean that Composer won't complain about @RC/@beta, but will complain about @alpha? And the workaround is to specify the exact alpha release version? I didn't know that!

Hmm I tried testing this and still got the following (with minimum-stability removed):

farmos/farmos 2.x-dev requires drupal/entity_reference_validators 1.0-alpha2 -> found drupal/entity_reference_validators[1.0.0-alpha2] but it does not match your minimum-stability

mmjvb’s picture

Indeed, your project needs drupal/entity_reference_validators @alpha because farmos/farmos wants 1,0-alpha2.

This is what I meant to be documented, a dependency requires a non-stable not allowed by the project. The project needs to allow that. So your project needs drupal/entity_reference_validators @alpha, to be adjusted to @beta, @RC or removed when stable. Having the primary requirement for drupal/entity_reference_validators is only needed as there is no stable version yet.

m.stenta’s picture

Ah gotcha! Thanks for the explanation - I'm still learning new things about Composer all the time. Appreciate the insights! :-)

Well, perhaps we can try to nudge drupal/entity_reference_validators to a beta release... that would be the best all around solution I think.

I worry about adding it as an @alpha requirement in our project's composer.json template, just because that will then need to be removed manually by anyone who uses the template in the future. Although I suppose once we require a non-alpha version in farmos/farmos that would serve as a not-so-gentle notification to do so for downstream projects.

mmjvb’s picture

When farmos/farmos is the template used for the project you need drupal/entity_reference_validators:1.0.0-alpha2 rather than 1.0-alpha2

docker@d92:/var/www$ composer show -a drupal/entity_reference_validators|grep versions
versions : 1.x-dev, 1.0.0-alpha2, 1.0.0-alpha1, dev-1.x
docker@d92:/var/www$

In my previous reply thought that template had requirement for farmos/farmos the profile

docker@d92:/var/www$ composer show farmos/farmos -a|grep \@
drupal/entity_reference_validators ^1.0@alpha
drupal/inline_entity_form ^1.0@RC
drupal/gin ^3.0@beta
docker@d92:/var/www$

These three need to be mentioned in the project template as :

drupal/entity_reference_validators @alpha
drupal/inline_entity_form @RC
drupal/gin @beta

Due to the nature of an alpha in semantic versioning would consider beta the minimum in a project.
Not sure about drupal/core 9.3.12, should be drupal/core ~9.3.12 at least for allowing bug fixes.

m.stenta’s picture

Thanks again @mmjvb - I did some more testing locally and I think I understand what's needed now.

1.0.0-alpha2 rather than 1.0-alpha2

Also thanks for pointing out this error... :-)

These three need to be mentioned in the project template..

Ah I see that now. We need to declare all three. That's a shame, but it makes sense. It makes me wonder if we should just postpone this until these projects are stable.

Not sure about drupal/core 9.3.12, should be drupal/core ~9.3.12 at least for allowing bug fixes.

We decided to pin all dependencies that we are patching, including Drupal core. I manually update this when security updates are released, currently.

mmjvb’s picture

You either mention them in the project template so you know there are transitive dependencies wanting non-stable releases or you pin them like those you patch.

Although waiting for a perfect world is possible, not convinced that ever will be the case. Going for stable releases as much as possible warrants the work in my opinion. On top of stable you already patch.

You might want to consider other patch facilities. You should be able to provide release specific patching.

m.stenta’s picture

Although waiting for a perfect world is possible, not convinced that ever will be the case. Going for stable releases as much as possible warrants the work in my opinion.

Agreed - that's why I keep coming back to this issue. I'd really like to remove minimum-stability and prefer-stable before our official 2.0.0 release if possible.

Oh! I just realized: I think we can put these in the farmos/farmos composer.project.json file, which gets merged into the project template composer.json during composer install (via https://github.com/wikimedia/composer-merge-plugin).

That would allow us to remove minimum-stability and prefer-stable from https://github.com/farmOS/composer-project AND we wouldn't have to add any transitory dependencies there... they could be added in the farmos/farmos repo, which we can easily remove later, without requiring downstream project maintainers make any changes.

I'll give this a quick test locally to confirm that it will work...

m.stenta’s picture

Hmm that doesn't seem to work, unfortunately. I suppose wikimedia/composer-merge-plugin's logic does not run before the dependency tree determination logic does. Unless I did something wrong...

m.stenta’s picture

Status: Active » Needs review

@mmjvb I've drafted a pull request: https://github.com/farmOS/composer-project/pull/8

What do you think?

The idea is: after we tag 2.0.0 of farmOS we can merge this. Then, if/as these dependencies release stable versions we can remove them from the project template composer.json.

Specifically I'm curious if this commit is roughly what you had in mind: https://github.com/farmOS/composer-project/pull/8/commits/a691e4758c8a81...

I used _comments to describe why these dependencies are included. I'm not sure if that's the best way to document, or if there are better alternatives.

mmjvb’s picture

No, not what I had in mind.

The farmOS/composer-project composer.json is the project template needing the three/four (farmos/farmos @beta) requirements to allow for non-stable transitive dependencies when removing minimum-stability.

You don't add the version constraint just the minimum stability. The version constraint belongs to the transitive dependencies, in this case the requirements of farmos/farmos.

The primary requirement of farmos/farmos in farmOS/composer-project needs to have ^2@beta as there is no stable release yet.

You don't add pinned dependencies to project template, there is absolutely no need for that. The minimum stability doesn't apply to pinned versions as there is no resolving the version, due to it being specified (pinned!)
No drupal/jsonapi_schema in template as it is pinned in farmos/farmos

m.stenta’s picture

OK I may have misunderstood your suggestions then.

I'm confused by this:

You don't add the version constraint just the minimum stability. The version constraint belongs to the transitive dependencies, in this case the requirements of farmos/farmos.

The goal of this issue is to remove minimum-stability from https://github.com/farmOS/composer-project/blob/2.x/composer.json (the project template). Are you suggesting we need to keep it?

Looking back at your previous comments...

Indeed, your project needs drupal/entity_reference_validators @alpha because farmos/farmos wants 1,0-alpha2.

This is what I meant to be documented, a dependency requires a non-stable not allowed by the project. The project needs to allow that. So your project needs drupal/entity_reference_validators @alpha

I must have misunderstood that. That is what this commit is doing, or so thought: https://github.com/farmOS/composer-project/pull/8/commits/a691e4758c8a81...

But you say that's not what you had in mind?

How do we achieve the goal of this issue (remove the minimum-stability and prefer-stable lines) in another way?

And just to respond to these two bits...

You don't add pinned dependencies to project template, there is absolutely no need for that. The minimum stability doesn't apply to pinned versions as there is no resolving the version, due to it being specified (pinned!)
No drupal/jsonapi_schema in template as it is pinned in farmos/farmos

Oh I thought I ran into an issue without it... but I will double check that...

The primary requirement of farmos/farmos in farmOS/composer-project needs to have ^2@beta as there is no stable release yet.

Sorry if that bit was confusing. Perhaps I didn't make it clear, but my broader intention is to tag a stable 2.0.0 of farmOS ASAP (we just have a few issues remaining). My plan was not to merge this PR alongside the 2.0.0 tagging of farmos/farmos, at which point `^2` would be the desired version constraint.

The next commit (https://github.com/farmOS/composer-project/pull/8/commits/a691e4758c8a81...) adds the alpha/beta/rc dependencies at the project level so that Composer doesn't complain when I remove the minimum-stability and prefer-stable lines in the last commit (https://github.com/farmOS/composer-project/pull/8/commits/b73d678a48128c...).

m.stenta’s picture

You don't add the version constraint just the minimum stability.

Oh I think I understand now... is this what you mean?

https://github.com/farmOS/composer-project/pull/8/commits/3d0ad2e3b1016d...

m.stenta’s picture

Update: Entity Reference Validators is now in beta! That was our last alpha dependency! :-D

mmjvb’s picture

Decided to give you some time to think about the information I provided. No idea what made you think I would be in favor of using minimum-stability. Just for the record: Should be removed from Composer configuration, bad idea to use it, even in combination with prefer-stable. Should be deprecated as far as I am concerned. So, not suggesting to keep it in your project!

See #27 for those needed to be primary requirements due to transitive requirements (farmos/farmos). There could be more needed, any non-stable transitive dependency should be recorded as primary. Again, pinned version are not needed as they ar not affected, you do need to specify correct tag.
There should be no objection to maintain this in your project template. That is what its purpose is. Do like your idea of adding it to a separate file, using composer-merge-plugin to make them primary requirements.
You could/should change alpha to beta for Entity Reference Validators, but that is a minor detail. No effect when not done!

Suggest to work the other way around, specify what works now and adjust to changed circumstances. Don't anticipate future releases other than in constraints. So, currently you have farmos/farmos only available in alpha, which should be reflected in farmos/composer-project. This allows you to test now, no need to wait for all work to be done. The definition will provide expected results when circumstances change. Don't know you development plans, when farmos/farmos beta arrives you can test that with current specifications.

Also like the way you document. Maybe moving it under extra key to keep it valid json. Possibly adding topic to get comments organized.

Received your message from Slack, don't mind but prefer the Forum and Issue queue. Consider Slack a hostile environment, both participants and governance. Discontinued participation in Slack.

m.stenta’s picture

Thanks again @mmjvb - I think I'm caught up to your thinking now. Appreciate the pointers. And agree re: Slack. ;-)

I think I'm on the right track now and I agree this can be adjusted/committed before farmOS 2.0.0. Might as well get it done and close this issue.

m.stenta’s picture

Issue tags: -stable blocker

I agree this can be adjusted/committed before farmOS 2.0.0. Might as well get it done and close this issue.

I found there's a bit of a chicken-and-egg with the farmos/farmos version constraint on this. So I've changed my mind and will wait to complete this until after 2.0.0 is released. Hopefully that will come together soon.

mmjvb’s picture

a bit of a chicken-and-egg with the farmos/farmos version constraint

What do you mean? Just trying to understand.

m.stenta’s picture

Very minor detail. I tried changing from "farmos/farmos": "2.x-dev" to "farmos/farmos": "^2@beta", ahead of the changes in this issue, but it fails because some of the beta releases depended on an alpha version of Gin:

- farmos/farmos[2.0.0-beta1, ..., 2.0.0-beta3] require drupal/gin 3.0-alpha37 -> found drupal/gin[3.0.0-alpha37] but it does not match your minimum-stability.
- Root composer.json requires farmos/farmos ^2@beta -> satisfiable by farmos/farmos[2.0.0-beta1, 2.0.0-beta2, 2.0.0-beta3, 2.0.0-beta4].

(beta1 through beta3 all depended on alpha Gin, beta4 updated Gin to its first beta release.)

I would rather just wait until we have a stable release of farmOS (coming very soon!) so that I can skip "farmos/farmos": "^2@beta" entirely and just use "farmos/farmos": "^2". That will bypass the Gin alpha thing... one less thing to keep in my head right now, which is already full.

mmjvb’s picture

That doesn't make sense!

farmos/farmos beta4 requires gin beta.

Where do you get the message about gin alpha? Are you doing something on farmos/farmos beta 1,2 or 3 ?

m.stenta’s picture

Download the composer.json from my 2.x-minimum-stability branch, run composer install and see if you get the same error that I pasted in my comment above: https://github.com/mstenta/farmOS-composer-project/tree/2.x-minimum-stab...

mmjvb’s picture

No problem

docker@cli:/var/www/farmos/farmOS-composer-project$ composer install --dry-run
No lock file found. Updating dependencies instead of installing from lock file. Use composer update over composer install if you do not have a lock file.
Loading composer repositories with package information
Info from https://repo.packagist.org: #StandWithUkraine
Updating dependencies
Lock file operations: 124 installs, 0 updates, 0 removals
  - Locking asm89/stack-cors (1.3.0)
  - Locking chi-teck/drupal-code-generator (1.33.1)
  - Locking composer/installers (v2.1.1)
  - Locking composer/semver (3.3.2)
  - Locking consolidation/annotated-command (4.5.5)
  - Locking consolidation/config (1.2.1)
  - Locking consolidation/filter-via-dot-access-data (1.0.0)
  - Locking consolidation/log (2.1.1)
  - Locking consolidation/output-formatters (4.2.2)
  - Locking consolidation/robo (3.0.10)
  - Locking consolidation/self-update (2.0.5)
  - Locking consolidation/site-alias (3.1.5)
  - Locking consolidation/site-process (4.2.0)
  - Locking cweagans/composer-patches (1.7.2)
  - Locking defuse/php-encryption (v2.3.1)
  - Locking dflydev/dot-access-data (v1.1.0)
  - Locking doctrine/annotations (1.13.2)
  - Locking doctrine/lexer (1.2.3)
  - Locking doctrine/reflection (1.2.2)
  - Locking drupal/admin_toolbar (2.5.0)
  - Locking drupal/config_update (1.7.0)
  - Locking drupal/consumers (1.12.0)
  - Locking drupal/core (9.3.9)
  - Locking drupal/csv_serialization (2.0.0)
  - Locking drupal/date_popup (1.1.0)
  - Locking drupal/entity (1.3.0)
  - Locking drupal/entity_browser (2.6.0)
  - Locking drupal/entity_reference_integrity (1.1.0)
  - Locking drupal/entity_reference_revisions (1.9.0)
  - Locking drupal/entity_reference_validators (1.0.0-beta1)
  - Locking drupal/exif_orientation (1.1.0)
  - Locking drupal/fraction (2.1.0)
  - Locking drupal/geofield (1.39.0)
  - Locking drupal/gin (3.0.0-beta3)
  - Locking drupal/gin_toolbar (1.0.0-beta22)
  - Locking drupal/inline_entity_form (1.0.0-rc11)
  - Locking drupal/inspire_tree (1.0.4)
  - Locking drupal/jsonapi_extras (3.20.0)
  - Locking drupal/jsonapi_schema (1.0.0-beta1)
  - Locking drupal/log (2.0.3)
  - Locking drupal/migrate_plus (5.3.0)
  - Locking drupal/migrate_tools (5.1.0)
  - Locking drupal/simple_oauth (5.0.6)
  - Locking drupal/state_machine (1.6.0)
  - Locking drupal/subrequests (3.0.3)
  - Locking drupal/token (1.10.0)
  - Locking drupal/views_geojson (1.1.0)
  - Locking drush/drush (10.6.2)
  - Locking e0ipso/shaper (1.2.4)
  - Locking egulias/email-validator (3.1.2)
  - Locking enlightn/security-checker (v1.10.0)
  - Locking farmos/farmos (2.0.0-beta4)
  - Locking galbar/jsonpath (1.3.1)
  - Locking grasmash/expander (1.0.0)
  - Locking grasmash/yaml-expander (1.4.0)
  - Locking guzzlehttp/guzzle (6.5.6)
  - Locking guzzlehttp/promises (1.5.1)
  - Locking guzzlehttp/psr7 (1.8.5)
  - Locking justinrainbow/json-schema (5.2.12)
  - Locking laminas/laminas-diactoros (2.11.0)
  - Locking laminas/laminas-escaper (2.10.0)
  - Locking laminas/laminas-feed (2.17.0)
  - Locking laminas/laminas-stdlib (3.7.1)
  - Locking lcobucci/jwt (3.4.6)
  - Locking league/container (3.4.1)
  - Locking league/csv (9.8.0)
  - Locking league/event (2.2.0)
  - Locking league/oauth2-server (8.1.1)
  - Locking masterminds/html5 (2.7.5)
  - Locking nikic/php-parser (v4.13.2)
  - Locking oomphinc/composer-installers-extender (2.0.1)
  - Locking paragonie/random_compat (v9.99.100)
  - Locking pear/archive_tar (1.4.14)
  - Locking pear/console_getopt (v1.4.3)
  - Locking pear/pear-core-minimal (v1.10.11)
  - Locking pear/pear_exception (v1.0.2)
  - Locking phayes/geophp (1.2)
  - Locking psr/cache (1.0.1)
  - Locking psr/container (1.1.2)
  - Locking psr/http-factory (1.0.1)
  - Locking psr/http-message (1.0.1)
  - Locking psr/log (1.1.4)
  - Locking psy/psysh (v0.10.12)
  - Locking ralouphie/getallheaders (3.0.3)
  - Locking stack/builder (v1.0.6)
  - Locking steverhoades/oauth2-openid-connect-server (v1.3.0)
  - Locking symfony-cmf/routing (2.3.4)
  - Locking symfony/console (v4.4.42)
  - Locking symfony/debug (v4.4.41)
  - Locking symfony/dependency-injection (v4.4.42)
  - Locking symfony/deprecation-contracts (v2.5.1)
  - Locking symfony/error-handler (v4.4.41)
  - Locking symfony/event-dispatcher (v4.4.42)
  - Locking symfony/event-dispatcher-contracts (v1.1.12)
  - Locking symfony/filesystem (v4.4.42)
  - Locking symfony/finder (v5.4.8)
  - Locking symfony/http-client-contracts (v2.5.1)
  - Locking symfony/http-foundation (v4.4.42)
  - Locking symfony/http-kernel (v4.4.42)
  - Locking symfony/mime (v5.4.9)
  - Locking symfony/polyfill-ctype (v1.25.0)
  - Locking symfony/polyfill-iconv (v1.25.0)
  - Locking symfony/polyfill-intl-idn (v1.25.0)
  - Locking symfony/polyfill-intl-normalizer (v1.25.0)
  - Locking symfony/polyfill-mbstring (v1.25.0)
  - Locking symfony/polyfill-php72 (v1.25.0)
  - Locking symfony/polyfill-php73 (v1.25.0)
  - Locking symfony/polyfill-php80 (v1.25.0)
  - Locking symfony/process (v4.4.41)
  - Locking symfony/psr-http-message-bridge (v2.1.2)
  - Locking symfony/routing (v4.4.41)
  - Locking symfony/serializer (v4.4.42)
  - Locking symfony/service-contracts (v2.5.1)
  - Locking symfony/translation (v4.4.41)
  - Locking symfony/translation-contracts (v2.5.1)
  - Locking symfony/validator (v4.4.41)
  - Locking symfony/var-dumper (v5.4.9)
  - Locking symfony/yaml (v4.4.37)
  - Locking twig/twig (v2.15.1)
  - Locking typo3/phar-stream-wrapper (v3.1.7)
  - Locking webflo/drupal-finder (1.2.2)
  - Locking webmozart/assert (1.10.0)
  - Locking webmozart/path-util (2.3.0)
  - Locking wikimedia/composer-merge-plugin (v2.0.1)
Installing dependencies from lock file (including require-dev)
Package operations: 124 installs, 0 updates, 0 removals
  - Installing cweagans/composer-patches (1.7.2)
  - Installing composer/installers (v2.1.1)
  - Installing wikimedia/composer-merge-plugin (v2.0.1)
  - Installing oomphinc/composer-installers-extender (2.0.1)
  - Installing symfony/polyfill-php80 (v1.25.0)
  - Installing symfony/polyfill-php73 (v1.25.0)
  - Installing symfony/polyfill-ctype (v1.25.0)
  - Installing symfony/polyfill-mbstring (v1.25.0)
  - Installing symfony/polyfill-php72 (v1.25.0)
  - Installing symfony/polyfill-intl-normalizer (v1.25.0)
  - Installing symfony/polyfill-intl-idn (v1.25.0)
  - Installing symfony/deprecation-contracts (v2.5.1)
  - Installing symfony/mime (v5.4.9)
  - Installing symfony/http-foundation (v4.4.42)
  - Installing symfony/http-client-contracts (v2.5.1)
  - Installing symfony/event-dispatcher-contracts (v1.1.12)
  - Installing symfony/event-dispatcher (v4.4.42)
  - Installing symfony/var-dumper (v5.4.9)
  - Installing psr/log (1.1.4)
  - Installing symfony/debug (v4.4.41)
  - Installing symfony/error-handler (v4.4.41)
  - Installing symfony/http-kernel (v4.4.42)
  - Installing asm89/stack-cors (1.3.0)
  - Installing twig/twig (v2.15.1)
  - Installing symfony/filesystem (v4.4.42)
  - Installing psr/container (1.1.2)
  - Installing symfony/service-contracts (v2.5.1)
  - Installing symfony/console (v4.4.42)
  - Installing chi-teck/drupal-code-generator (1.33.1)
  - Installing dflydev/dot-access-data (v1.1.0)
  - Installing consolidation/filter-via-dot-access-data (1.0.0)
  - Installing symfony/yaml (v4.4.37)
  - Installing symfony/process (v4.4.41)
  - Installing symfony/finder (v5.4.8)
  - Installing league/container (3.4.1)
  - Installing composer/semver (3.3.2)
  - Installing consolidation/self-update (2.0.5)
  - Installing consolidation/output-formatters (4.2.2)
  - Installing consolidation/log (2.1.1)
  - Installing grasmash/expander (1.0.0)
  - Installing consolidation/config (1.2.1)
  - Installing consolidation/annotated-command (4.5.5)
  - Installing consolidation/robo (3.0.10)
  - Installing consolidation/site-alias (3.1.5)
  - Installing consolidation/site-process (4.2.0)
  - Installing paragonie/random_compat (v9.99.100)
  - Installing defuse/php-encryption (v2.3.1)
  - Installing psr/cache (1.0.1)
  - Installing doctrine/lexer (1.2.3)
  - Installing doctrine/annotations (1.13.2)
  - Installing doctrine/reflection (1.2.2)
  - Installing typo3/phar-stream-wrapper (v3.1.7)
  - Installing symfony/translation-contracts (v2.5.1)
  - Installing symfony/validator (v4.4.41)
  - Installing symfony/translation (v4.4.41)
  - Installing symfony/serializer (v4.4.42)
  - Installing symfony/routing (v4.4.41)
  - Installing psr/http-message (1.0.1)
  - Installing symfony/psr-http-message-bridge (v2.1.2)
  - Installing symfony/polyfill-iconv (v1.25.0)
  - Installing symfony/dependency-injection (v4.4.42)
  - Installing symfony-cmf/routing (2.3.4)
  - Installing stack/builder (v1.0.6)
  - Installing pear/pear_exception (v1.0.2)
  - Installing pear/console_getopt (v1.4.3)
  - Installing pear/pear-core-minimal (v1.10.11)
  - Installing pear/archive_tar (1.4.14)
  - Installing masterminds/html5 (2.7.5)
  - Installing laminas/laminas-stdlib (3.7.1)
  - Installing laminas/laminas-escaper (2.10.0)
  - Installing laminas/laminas-feed (2.17.0)
  - Installing psr/http-factory (1.0.1)
  - Installing laminas/laminas-diactoros (2.11.0)
  - Installing ralouphie/getallheaders (3.0.3)
  - Installing guzzlehttp/psr7 (1.8.5)
  - Installing guzzlehttp/promises (1.5.1)
  - Installing guzzlehttp/guzzle (6.5.6)
  - Installing egulias/email-validator (3.1.2)
  - Installing drupal/core (9.3.9)
  - Installing drupal/consumers (1.12.0)
  - Installing drupal/gin_toolbar (1.0.0-beta22)
  - Installing justinrainbow/json-schema (5.2.12)
  - Installing e0ipso/shaper (1.2.4)
  - Installing enlightn/security-checker (v1.10.0)
  - Installing phayes/geophp (1.2)
  - Installing webmozart/assert (1.10.0)
  - Installing webmozart/path-util (2.3.0)
  - Installing webflo/drupal-finder (1.2.2)
  - Installing nikic/php-parser (v4.13.2)
  - Installing psy/psysh (v0.10.12)
  - Installing grasmash/yaml-expander (1.4.0)
  - Installing drush/drush (10.6.2)
  - Installing drupal/views_geojson (1.1.0)
  - Installing drupal/token (1.10.0)
  - Installing galbar/jsonpath (1.3.1)
  - Installing drupal/subrequests (3.0.3)
  - Installing drupal/state_machine (1.6.0)
  - Installing league/event (2.2.0)
  - Installing lcobucci/jwt (3.4.6)
  - Installing league/oauth2-server (8.1.1)
  - Installing steverhoades/oauth2-openid-connect-server (v1.3.0)
  - Installing drupal/simple_oauth (5.0.6)
  - Installing drupal/migrate_plus (5.3.0)
  - Installing drupal/migrate_tools (5.1.0)
  - Installing drupal/entity (1.3.0)
  - Installing drupal/log (2.0.3)
  - Installing drupal/jsonapi_schema (1.0.0-beta1)
  - Installing drupal/jsonapi_extras (3.20.0)
  - Installing drupal/inspire_tree (1.0.4)
  - Installing drupal/inline_entity_form (1.0.0-rc11)
  - Installing drupal/gin (3.0.0-beta3)
  - Installing drupal/geofield (1.39.0)
  - Installing drupal/fraction (2.1.0)
  - Installing drupal/exif_orientation (1.1.0)
  - Installing drupal/entity_reference_validators (1.0.0-beta1)
  - Installing drupal/entity_reference_revisions (1.9.0)
  - Installing drupal/entity_reference_integrity (1.1.0)
  - Installing drupal/entity_browser (2.6.0)
  - Installing drupal/date_popup (1.1.0)
  - Installing league/csv (9.8.0)
  - Installing drupal/csv_serialization (2.0.0)
  - Installing drupal/config_update (1.7.0)
  - Installing drupal/admin_toolbar (2.5.0)
  - Installing farmos/farmos (2.0.0-beta4)
38 package suggestions were added by new dependencies, use `composer suggest` to see details.
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Package webmozart/path-util is abandoned, you should avoid using it. Use symfony/filesystem instead.
docker@cli:/var/www/farmos/farmOS-composer-project$
m.stenta’s picture

Huh. I run Composer in Docker (not installed locally), and I was testing with the official Docker Hub composer image, which caused those errors to appear.

sudo docker run -it --rm -v $PWD:/app composer install

However, I'm testing again now with the farmos/farmos:2.x Docker image, and it is working.

sudo docker run -it --rm -v $PWD:/opt/drupal farmos/farmos:2.x composer install

I know that the composer image is PHP 8, and farmos/farmos:2.x is PHP 7.4 - maybe that is why I was seeing something different.

It is working now. This makes me want to re-run some of my previous tests (eg: with composer-merge-plugin) to see if they will work differently too.

Thanks for double-checking this @mmjvb.

m.stenta’s picture

Version: 2.x-dev » 3.x-dev
m.stenta’s picture

Version: 3.x-dev » 4.x-dev
m.stenta’s picture

Issue summary: View changes

Been a long time since I looked at this....

entity_reference_validators, gin, and jsonapi_schema have all had stable releases in the meantime.

The only ones left are inline_entity_form (see: #2576445: Inline Entity Form stable release plan) and config_update (see: #3384689: Provide stable 2.0 release).