| [04:00:07] | * skalakm[m] has quit (Quit: Idle for 30+ days) |
| [08:33:02] | <mstenta[m]> | Hmm so I updated `composer-project/composer.json` to use `"drupal/core-dev": "^9.0.0",` - but it still seems to be installing 9.1... |
| [08:33:21] | <mstenta[m]> | https://github.com/farmOS/composer-project/commit/47b94872d14f5c5a61ae4d... |
| [08:33:38] | <mstenta[m]> | https://pipelines.actions.githubusercontent.com/af6k4ejNexDepsF135qFTH7r... |
| [08:33:56] | <mstenta[m]> | https://github.com/mstenta/farmOS/runs/1492791437 |
| [08:54:59] | <mstenta[m]> | Ah! Doh. Needs to be `~9.0.0` not `^9.0.0` :-) |
| [10:17:33] | <mstenta[m]> | Fyi paul121 and symbioquine I'm testing updating to Drupal 9.1.0, so you may see failing tests today from that |
| [10:18:42] | <mstenta[m]> | Looks like we just need to update a few things for PHPUnit 9 |
| [11:00:56] | <symbioquine[m]> | I've been finding some interesting details on that basic auth prompt that was occurring for invalid oauth client ids; https://github.com/thephpleague/oauth2-server/issues/1162 |
| [11:01:59] | <symbioquine[m]> | Seems like it's caused by the how the default Drupal .htaccess configuration interacts with thephpleague/oath2-server's exception handling. |
| [11:46:50] | <symbioquine[m]> | paul121: mstenta Are you guys using `drush site-install` for your 2.x development setup? |
| [11:47:30] | <symbioquine[m]> | ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/cqftQfmPXIBEgnPT... > |
| [11:48:25] | <mstenta[m]> | No I haven't tried `drush site-install` on 2.x yet |
| [11:48:33] | <mstenta[m]> | Been installing manually |
| [11:48:58] | <mstenta[m]> | Hmm |
| [11:49:19] | <mstenta[m]> | So... |
| [11:49:38] | <mstenta[m]> | the `farm_settings` module uses the `FarmModulesForm`... but `FarmModulesForm` is provided by the distro, not a module |
| [11:49:49] | <mstenta[m]> | Must be something to do with the way that's set up? |
| [11:49:56] | <symbioquine[m]> | huh |
| [11:50:01] | <mstenta[m]> | But a manual install works for you? |
| [11:50:05] | <symbioquine[m]> | yeah |
| [11:50:15] | <symbioquine[m]> | The module it's talking about does exist. |
| [11:51:31] | * aislinnpearson[m has joined #farmos |
| [11:52:04] | <mstenta[m]> | Hmm |
| [11:52:10] | <paul121[m]> | module load include? |
| [11:52:59] | <mstenta[m]> | It sounds like `farm_settings` is being installed, but can't autoload the `FarmModuleForm` class? Is that right? |
| [11:53:36] | <symbioquine[m]> | I assume that's right. I can't say I'm super clear on what the stack trace is actually saying... |
| [11:53:40] | <mstenta[m]> | symbioquine: You could try commenting out the `farm_settings` line in `farm.info.yml` and just see if that allows `drush site-install` to proceed |
| [11:54:06] | <symbioquine[m]> | naively, I would have read it as saying that the module didn't exist, but it might be saying something more complicated about why it couldn't load it. |
| [11:54:17] | <symbioquine[m]> | <mstenta[m] "symbioquine: You could try comme"> yeah, just a sec |
| [11:55:05] | <paul121[m]> | the form in `farm_settings` extends the `FarmModulesForm` from the `farm` profile code, which isn't a module |
| [11:55:22] | <paul121[m]> | maybe there is a weird bug there? |
| [11:55:39] | <symbioquine[m]> | <symbioquine[m] "yeah, just a sec"> That worked. |
| [11:55:48] | <mstenta[m]> | yea that seems like the likely explanation |
| [11:55:54] | <mstenta[m]> | ah cool - ok hmm... |
| [11:56:11] | <mstenta[m]> | (i have to sign off in ~5 so might want to start an issue for this) |
| [11:56:47] | <mstenta[m]> | perhaps we should run `drush site-install` in our `run-tests.yml` to catch stuff like this |
| [11:58:03] | <mstenta[m]> | On another topic... I think we will need to turn off PHPUnit deprecation warnings... I tried updating us to Drupal 9.1.0 and there's one set of warnings in upstream contrib modules that we can't fix ourselves (unless we patch all of them). |
| [11:59:54] | <symbioquine[m]> | <mstenta[m] "On another topic... I think we w"> Maybe that expected deprecations approach paul121 mentioned could be put in the test base class as a work-around which would still allow in-src deprecations to be caught? |
| [12:00:11] | <symbioquine[m]> | <mstenta[m] "(i have to sign off in ~5 so mig"> Will do |
| [12:00:48] | <mstenta[m]> | > Maybe that expected deprecations approach paul121 mentioned could be put in the test base class as a work-around which would still allow in-src deprecations to be caught? |
| [12:00:48] | <mstenta[m]> | remind me how this works? |
| [12:02:42] | <paul121[m]> | oh I'm not sure if that would work here.. I think we would need symbioquine approach to catch all deprecations |
| [12:03:12] | <symbioquine[m]> | <paul121[m] "https://symfony.com/doc/current/"> This is what I was referring to |
| [12:03:43] | <paul121[m]> | what I mentioned is that there is a PHPUnit assertion method, something like `$this->expectDeprecation()`, but that only works in the individual test case method |
| [12:05:33] | <symbioquine[m]> | Oh, bummer |
| [12:05:53] | <symbioquine[m]> | What about turning off just the indirect deprecation warnings? https://symfony.com/doc/current/components/phpunit_bridge.html#direct-an... |
| [12:08:36] | <paul121[m]> | that looks good! |
| [12:14:49] | <mstenta[m]> | Oh interesting does |
| [12:14:59] | <mstenta[m]> | Indirect mean upstream? |
| [12:16:07] | <paul121[m]> | I think so, the difference being `direct` = dependency, `indirect` = dependency of a dependency ? |
| [12:16:52] | <paul121[m]> | and `self` = our src? |
| [12:26:58] | <symbioquine[m]> | That's what I was assuming too |
| [12:27:37] | <mstenta[m]> | Would that just require a tweak to our phpunit.xml? |
| [12:27:55] | <symbioquine[m]> | yeah, I think so |
| [12:28:13] | <mstenta[m]> | Speaking of... also seeing this now (not causing a failure, but maybe we can do this too) |
| [12:28:17] | <mstenta[m]> | ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/xeMosCPmHzNODanE... > |
| [12:56:18] | <paul121[m]> | everything is deprecated! #DeprecateDecember |
| [12:56:29] | <paul121[m]> | jk. I like December. |
| [12:56:33] | <mstenta[m]> | haha |
| [12:56:39] | <mstenta[m]> | #Deprecate2020 |
| [13:03:05] | <mstenta[m]> | Do you think `max[direct]=0` would make the most sense, based on that documentation? |
| [13:03:12] | <mstenta[m]> | > Recommended for projects with dependencies that fail to keep up with new deprecations. |
| [13:04:17] | <mstenta[m]> | (I just submitted a test commit to my fork to see if it works... but I'm not sure if my `sed` is correct... we'll see...) |
| [13:19:19] | <mstenta[m]> | > not sure if my `sed` is correct |
| [13:19:19] | <mstenta[m]> | narrator: it was not. |
| [13:22:25] | <mstenta[m]> | try again... |
| [13:49:01] | <mstenta[m]> | `max[direct]=0` does not work. |
| [13:49:29] | <mstenta[m]> | i then tested `disabled=1` to confirm that my change was applying, and that DID work. |
| [13:49:37] | <mstenta[m]> | so i think we just need to hone in on the right setting here |
| [13:49:43] | <mstenta[m]> | i' |
| [14:15:31] | <mstenta[m]> | tested with `quiet[]=indirect` and that seems to work |
| [14:15:52] | <mstenta[m]> | i'll push a commit up with that for now, and we can test/refine if necessary |