Drupal 9 readiness meeting / 9 December 2019 [#3093746]

Meeting will happen in #d9readiness on drupal.slack.com.

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 9 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3093746`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

:zero: Who is here today? Comment in the thread below to introduce yourself.

mglaman	:wave: Matt here,
Alona Oneill	Alona from SF. Hook42. Taking notes for blog
tedbow	:wave:Ted in from NY state
dan2k3k4	:wave: Dan, in Zurich :flag-ch: (edited)
mikelutz	Hi all!
shaal	:wave: Ofer Shaal, Florida
mixologic	Oh, howdy
mixologic	Im here
greg.1.anderson	@greg.1.anderson multitasking but here
Gábor Hojtsy (he/him)	:wave:
catch	Nat, quite late.
vuil	Drupal projects / modules contributor.
wimleers (he/him)	:wave: >48 hours after the fact, catching up :stuck_out_tongue:
vuil	I regularly go through all the posts, though later ... :laughing:

:one: Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.

mglaman	PHPStan 0.12, phpstan-drupal compat + drupal-check
dan2k3k4	Anything planned for Global Contribution Weekend 2020 on Friday, 24. January 2020 - Sunday, 26. January 2020?Would promoting D9 code sprints in different places help, or perhaps being available as remote mentors for those who want to work on upgrading their modules during the weekend?
Krzysztof Domański	#2662898: "Links" field not displaying on custom view modes
Krzysztof Domański	"Links" field not displaying on custom view modes. There are many view modes in which we can break design when we fix it. That's because the configuration is "enabled" by default. Is there any BC for this? Is such a change allowed in major Drupal version like 9.0.0 despite effecting multiple sites?
Krzysztof Domański	---
Krzysztof Domański	Is there a plan to introduce <?php declare(strict_types = 1); to increase control over data types in Drupal 9? What impact will it have on BC? (edited)
vuil	Good question @Krzysztof Domański!

:two: Drupal 9 alpha1 is one issue away apparently

:three: PHPStan 0.12, phpstan-drupal compatibility + drupal-check

Gábor Hojtsy (he/him)	Based on #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1 it looks like there is one requirement left
Gábor Hojtsy (he/him)	#3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates
Gábor Hojtsy (he/him)	there are also 2 should haves
Gábor Hojtsy (he/him)	#3091418: Update composer dependencies on 9.0.x following PHP 7.2 requirement
Gábor Hojtsy (he/him)	and #3075954: Remove duplicate scaffold files
Gábor Hojtsy (he/him)	help would be welcome on updating composer dependencies
Gábor Hojtsy (he/him)	@greg.1.anderson may have an update on the scaffold files issue :slightly_smiling_face:
Gábor Hojtsy (he/him)	it seems to be postponed on the tarball building issue which is already happening AFAIK(?) but not entirely reflected on the issue
tedbow	The first I am working and I think is getting pretty close. Working with drumm to determine what we need the /current XML feed.
greg.1.anderson	Yeah, it's just tarball creation that's holding up removing the duplicate scaffold files in Drupal 9. That work is in progress right now (cc @mixologic)
mixologic	Yep. still feeling like I've got 5 rivers converging on my floodplains.
greg.1.anderson	lmk if there are any tools / scripts / PRs I could provide to help knock out one of your todos
mixologic	@greg.1.anderson one thing that could help is figuring out what I need to do in drupalci to make testing against 8.8.0 work. Basically, git clone drupal;composer require some module;is what is supposed to work, but due to the composer.lock being out of sync with composer.json things break. Im pretty sure it might just be composer update --lock or something simple in between. Ideally something that can run always that would noop in most cases.
greg.1.anderson	@mixologic Why is composer.lock out of sync with composer.json? What error is returned, at what stage?
mixologic	This was the issue where the 8.8.0 tag still has 8.8.x-dev in the lockfile for drupal/core (the lockfile in the git repo)
mixologic	https://www.drupal.org/pift-ci-job/1498058 is an example of a contrib test that fails
mixologic	https://dispatcher.drupalci.org/job/drupal_contrib/94054/console
greg.1.anderson	Ah, so you're doing a git clone of the tag, and then the composer require of the module fails?
mixologic	yes. as that how we run contrib module tests.
mixologic	But the tag is angry about the lock file.
mixologic	14:20:06 Problem 114:20:06 - Conclusion: don't install drupal/core 8.8.014:20:06 - Can only install one of: drupal/core[8.8.0, 8.8.x-dev].14:20:06 - Can only install one of: drupal/core[8.8.x-dev, 8.8.0].14:20:06 - Can only install one of: drupal/core[8.8.0, 8.8.x-dev].14:20:06 - Installation request for drupal/core 8.8.0 -> satisfiable by drupal/core[8.8.0].14:20:06 - Installation request for drupal/core (locked at 8.8.x-dev, required as self.version) -> satisfiable by drupal/core[8.8.x-dev].
greg.1.anderson	Yeah, I see that now. Provide a link to the code that's running that step?
mixologic	Its low hanging, probably just composer lock update before requiring the contrib project.
mixologic	This is the plugin that does the core_install
mixologic	https://git.drupalcode.org/project/drupalci_testbot/blob/dev/src/DrupalC...
greg.1.anderson	To me it looks like installed.json somehow got Drupal 8.8.0 stable, but composer.lock has 8.8.x-dev. Maybe
mixologic	but Im mostly just hoping to lateral pass the composer commands
mixologic	yeah, I think thats exactly the issue.
mixologic	But yeah, dont sweat making a patch for drupalci, mostly just see if you can clone/doesomething/require contrib
greg.1.anderson	Yeah I can do that; I just need to reproduce the setup steps.
mixologic	check the console logs: https://dispatcher.drupalci.org/job/drupal_contrib/94054/console
greg.1.anderson	Can I browse the contents of packages.drupal.org online if I want to see a composer.json w/out installing the module?
mixologic	Not really. But you can do it with composer show -a drupal/projectname:version
mixologic	but that will also download the whole metadata into your cache where you can see the raw json
mixologic	i.e. for that contrib test I linked to:composer -vvv show -a drupal/minisite
mixologic	I seeDownloading https://packages.drupal.org/8/drupal/minisite%24c5d727ec199da9c3573cd920... the output
mixologic	oh, actuallyWriting /Users/ryan/.composer/cache/repo/https---packages.drupal.org-8/provider-drupal$minisite.json into cache
greg.1.anderson	Yeah so it looks like module foo requires drupal/core at some stable version
greg.1.anderson	That's where the conflict is coming in.
greg.1.anderson	I am guessing that when we test modules, we always want to do so against a stable drupal
greg.1.anderson	and the only problem is that the stable Drupal has a dev drupal/core in its lock file.
greg.1.anderson	Ultimately, I guess, fix the lock file.
Gábor Hojtsy (he/him)	proposed by @mglaman
mglaman	phpstan 0.12 came out which changes a lot. phpstan is now a phar by default, which fixes autoloading collisions!
mglaman	but it broke things.
mglaman	Immediate goal is to point out phpstan-drupal as 0.11.0 only - https://github.com/mglaman/phpstan-drupal/pull/95This test is failing, but maybe I just need to merge and see?
mglaman	Issues for 0.12.0 support:phpstan-drupal https://github.com/mglaman/phpstan-drupal/issues/91drupal-check: https://github.com/mglaman/drupal-check/issues/117
mglaman	the conflict identification is for #3099396: PHPStan job must identify it conflicts with 0.12, so the deprecation reports can keep running
mglaman	@Gábor Hojtsy (he/him) @mixologic the conflicts in PR#95 for phpstan-drupal seem to make sense, but are failing in the test. I wonder if its just due to wonky testing of a local sourced path? maybe just merge and test somewhere
Gábor Hojtsy (he/him)	@mglaman I will need to update https://git.drupalcode.org/project/upgrade_status/blob/8.x-1.x/composer.... too with similar :slightly_smiling_face:
Gábor Hojtsy (he/him)	so that should serve as testing also :slightly_smiling_face:
mglaman	well, really if the conflict is in phpstan-drupal that should inherit the same conflict? or does it not quite work that way
Gábor Hojtsy (he/him)	possibly yes
mglaman	One thing I was wondering is if conflicts are treated like require-dev, only on the root of the project :confused:.
Gábor Hojtsy (he/him)	I’d love to move to require drupal-check and exec() it eventually, see #3085327: If curl cannot connect, use exec directly and don't use the curl sandboxing that would clear out a lot of the syncing needs between the tools
mixologic	This feels like its 4 problems.
mixologic	drupal-check needs fixing
mixologic	2. upgrade_status needs fixing
mixologic	3. drupalci phpstan build step needs fixing
mixologic	and 4. static analysis all projects needs fixing.
mglaman	(it is 4 problems)
mixologic	and Im unsure what it is we need to do
mglaman	one quick-fix is identifying the conflict, that solves 3&4
mglaman	so deprecations-rules stops trying to pull 0.12
mixologic	what requires deprecations-rules ?
mglaman	that's what groks @deprecated, but upgrae_status and the build step composer require it
mglaman	the build step runs composer require phpstan/phpstan-deprecation-rules after it requires phpstan-drupal
mixologic	where did the requirement for^0.12.0 come from?
mglaman	that's the Q, composer just picks it
mglaman	@mixologic see https://circleci.com/gh/mglaman/phpstan-drupal/262the composer.json just had ^0.11.0
mglaman	for some reason Composer flips a table
mixologic	gotcha so its phpstan-drupal thats getting a higher version of phpstan
mixologic	which is probably because this doesnt have 3 version places: https://github.com/mglaman/phpstan-drupal/blob/master/composer.json#L14
mixologic	Im not entirely sure, but it might work if its ^0.11.0
mglaman	@mixologic which I changed in the PR to ~0.11.0
mixologic	ah. but still breaks?
mglaman	https://github.com/mglaman/phpstan-drupal/pull/95, see builds
mglaman	https://circleci.com/gh/mglaman/phpstan-drupal/264
mglaman	Composer is still pulling phpstan/phpstan-deprecation-rules 0.12.0 and blowing my mind
mglaman	but it's also pulling the package from a symlink, and I feel like that randomly breaks some metadata shit
mglaman	so I'm tempted to just merge as is and tag a release and see
mixologic	yeah, I think thats something to do with how composer behaves with regards to dev releases.
mglaman	When does the phpstan job build?
Gábor Hojtsy (he/him)	@mglaman the all contrib one weekly, the contrib individual ones anytime they run
mixologic	so for both drupalci and the phpstan job, I can just add phpstan/phpstan:0.11 to the require and force it to be that version
mixologic	it runs once a week or whenever I push the button (edited)
mglaman	can we try pushing the button after I tag a release? see if the conflict statements worked
mglaman	I was hoping this would work so we don't have workarounds in drupalci-land
mixologic	Do you want to do that? I was just going to shoehorn in this for now:-composer require mglaman/phpstan-drupal phpstan/phpstan-deprecation-rules --dev+composer require mglaman/phpstan-drupal phpstan/phpstan-deprecation-rules phpstan/phpstan:0.11.19 --dev

:four: Plans for Global Contribution Weekend Friday, 24. January 2020 - Sunday, 26. January 2020

Gábor Hojtsy (he/him)	@dan2k3k4 raised this
Gábor Hojtsy (he/him)	I also tweeted this on last Thursday :smile: https://twitter.com/gaborhojtsy/status/1202647375090716672
mglaman	I plan on trying to do a phpstan-drupal sprint that week for 0.12 compatibility, better static analysis setups
Gábor Hojtsy (he/him)	@mglaman what would be amazing is to merge the global constants POC that you did :slightly_smiling_face:
mglaman	merge it as is?
mglaman	or improve on it
Gábor Hojtsy (he/him)	@mglaman I don’t think we’ll figure out finding dynamically, so hardcoding them is still better to find them :smile:
mglaman	merged
mglaman	so we can expand on that manually in the sprint
Gábor Hojtsy (he/him)	yay!
Gábor Hojtsy (he/him)	I hope to provide a 1-pager getting started summary for people which would like to the right pages :slightly_smiling_face:
Gábor Hojtsy (he/him)	maybe a flowchart or some visuals to help get started / pick the tools also
Gábor Hojtsy (he/him)	@dan2k3k4 last month, we launched https://dev.acquia.com/drupal9/deprecation_status which should help at contribution events like this :slightly_smiling_face:
dan2k3k4	@Gábor Hojtsy (he/him) yep I'll help to "promote" this at the talk I plan on doing the week before (also in Zurich) :slightly_smiling_face:

:five: Is there a plan to introduce <?php declare(strict_types = 1); to increase control over data types in Drupal 9?

Gábor Hojtsy (he/him)	topic proposed by @Krzysztof Domański
mglaman	I think I saw an issue for it, there is a plan to try and add it in a scoped small fashion
Gábor Hojtsy (he/him)	there is at least this from June #3060914: All new Drupal 8/9 code must use strict type hints where possible
Gábor Hojtsy (he/him)	despite the title it is not an official mandate(!)
Gábor Hojtsy (he/him)	#3050720: [Meta] Implement strict typing in existing code is the core issue

:six: “Links” field not displaying on custom view modes. There are many view modes in which we may break designs when we fix it.

Gábor Hojtsy (he/him)	@Krzysztof Domański proposed this topic
Gábor Hojtsy (he/him)	issue at #2662898: "Links" field not displaying on custom view modes
Krzysztof Domański	How can we fix this with BC? Is this allowed in major Drupal 9.0.0 despite effecting multiple sites (info in release notes)? (edited)
Gábor Hojtsy (he/him)	I don’t personally know the answer, let’s see who is on the issue
Gábor Hojtsy (he/him)	this would be some combination of @catch and/or @lauriii :)
berdir	we could have an update function that disables it on all view modes where it was previously enabled but wouldn't work?
berdir	then you have to re-enable it if you want to show it?
berdir	wouldn't work for default config in modules/install profiles, but we broke things like that before, with config schema changes and so on
catch	This is a good idea https://drupal.slack.com/archives/CDDD98AMN/p1575921589192400?thread_ts=...
Gábor Hojtsy (he/him)	@Krzysztof Domański looks like you way to solving it ^^^ :slightly_smiling_face:
catch	Having said that though - what happens if you have other links on nodes like comment count or similar? Don't think we should update configuration just because of the read more link.
catch	Posted #2662898: "Links" field not displaying on custom view modes#comment-13384707
berdir	yeah, other links are tricky, I think it's just read more with that hardcoded check, so the others would show up. I don't think my idea works then (edited)
catch	If the other links show up properly, I don't think we need to do anything - sites may well already have links showing.
andypost	at least in search we still hardcode view modes for links, added related issues #2662898: "Links" field not displaying on custom view modes#comment-13384765 (edited)

:seven: Highfives for removing half of the deprecated APIs from core already! (edited)

Gábor Hojtsy (he/him)	We put up a graph of this at https://dev.acquia.com/drupal9/deprecation_status/graphs — it really is truly impressive to see :slightly_smiling_face:
Gábor Hojtsy (he/him)	down to less than half of what it was a month ago :slightly_smiling_face:
Gábor Hojtsy (he/him)	Screenshot 2019-12-09 at 20.49.27.png
Gábor Hojtsy (he/him)	the other half is still to do :slightly_smiling_face: #2716163: [META] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules on the Drupal 9 branch
Gábor Hojtsy (he/him)	has a bunch of RTBC child issues and some needs work
berdir	#3087644: Remove Drupal 8 updates up to and including 88** is a blocker for a lot of the remaining ones as we can't remove BC layers that are still used by the upgrade path
berdir	does that need sign-off from someone to get in, e.g. @xjm?
Gábor Hojtsy (he/him)	or @catch :slightly_smiling_face:
berdir	@catch already RTBC'd the policy/parent issue, so I assumed it needs someone else
Gábor Hojtsy (he/him)	@catch would discuss with @xjm as needed, so I don’t think so :)
berdir	k. not urgent, but at least entity, path_alias and views BC removal issues are blocked on that one, so once that is in these should be ready soon after too I hope
catch	I wanted to talk through it with xjm before committing, but she's off this week so it probably won't be immediate.
catch	but for me I think it's ready to go given we've got the 88+ database dumps now.