Podcast audio transcript

DrupalEasy Podcast 235 - Nils Adermann (Composer co-author), DrupalCon Global chat

Audio transcript

Intro

[0:00] Hey, now welcome to DrupalEasy Podcast Episode 235.
My name is Mike Anello, and on this episode I had the pleasure of interviewing nils Adermann, one of the co authors of the composer project.
Also, Ryan price and I sit down for a little chat, mainly about the DrupalCon global chat and all the chatter about the job.

[0:23] But before we get to that, let me quickly mention some DrupalEasy training that we have coming up.
Monday, August 24th and Tuesday, August 25th Parts one and two of our composer Basics for drupal Developers Online Workshop.
You can check that out at DrupalEasy dot com slash composer Dash basics as well as on September 8th and November 10th our to our professional local development with D Dev Workshop.
And, of course, don't forget about drupal Career online, our flagship training program.
12 weeks, 3/2 days a week.

[1:03] Next semester begins August 31st. If you want to learn more, we actually have free information. Webinars On July 22nd on this 12th and August 26 you can get more information about drupal career online at DrupalEasy dot com.
Flash D. C.

[1:18] Music.

 

 

Nils Adermann Interview

[1:25] I'm here with one of the composer co founders co leads nils Adermann. It nils Adermann doing really well. Thanks for having me on the show.

[1:36] So when you introduce yourself, which how do you describe yourself in your relationship to composer co-lead is that I usually go with co author because I feel like I did do a lot of the initial work.
But in the day to day maintenance today, I don't play that big of a role anymore.
I think I have, like some very specific areas that have focused on which have to do with dependency resolution on a few other respects Now on the version two that we're working on.
But I think the main day to day maintenance work answering support issues, dealing with all the reports as Jordi Biaggiano was doing that these days.

[2:13] All right, Very good. So as you note the drupal community, pretty much adopted composer for you, starting with drupal. Eight and the usage among drupal developers, as far as I can tell, is just going up and up in office.
This folks realize that this is really the best way to manage a code base.
You know, it's it's possible with drupal eight and drupal nine to manage a code based out composer, but it's getting more and more difficult as we progress.
So with composer to on the near horizon, I figured it would be a good time to have you on, and we can talk a little bit about the improvements that are coming composer to.

[2:52] But before we get to that, I was curious about how did this composer project get started?
Did you see, like, ah, hole in the ecosystem or kind of what was the genesis of the project s.
So I started working on Composer as a new management will for plug ins in the Forum software Ph.
PBB back in 2011 So Ph B.
B B has been around for quite a while. I'm sure that a lot of people still remember it, or some may even still use it to date on.
We were looking into building the way that plug ins work for the system and at the same time started looking into using some of the symphony framework symphony components very much of verses that drupal went to, uh, more recently than PHP BB.
Like then, um, and in that process, I got in touch with a lot of members of the symphony community and in particularly Jordi I mentioned earlier was one of them.
And so the two of us together decided to build a tool that might help with a time it was Symphony to Is the new version the current versions a really a natural progression off that architecture.

[4:03] Which had a concept off bundles, very much like plug ins that also needed to be installed it. So we wanted to build a tool that would solve this problem both for us, with PHP Bt to install plug ins and for a symphony to install these bundles.
And so we ended up building a more generic tool that eventually ended up helping any PHP developer because it was not specifically tied to with that framework for the project I was working on.
So when we first started, we didn't actually set out to build a tool that was generally useful to PHP developers but more specific to our projects that we were working on.
And the entire cage key community, I think, has been going through that transition that you just mentioned drupal developers They're going through for the last 10 years old together now.
And there's definitely all these different nations projects like drupal has like a particular set of developers that most of work with drupal.
But then before then there were a gentle developers who went to this solution at some point where people who worked with other content management systems, people work with specific frameworks things.
Then Framework was one of the early adopters actually off composer already in 2012.
So developers working with that where Larry Bell developers is that So I think all these projects one after another at some point realized the value.
Andi think at this point it's just so. Bradley used that It really just makes sense for drupal to go through the same transition.

[5:30] So the first release was in 2012. So was that first release. Was that like a generic PHP will release? Or was that still more geared towards Ph PBB?
No. So this was a generic tool from the beginning on, I think the idea behind what we were building was originally focused on those two things. But we never build anything tied into PHP PP or specifically to symphony.
So from the very first development versions, even in 2011 before there was a release, is just a generic command line utility that you could use for anything.
And some frameworks even started using this in 2011 before there was any kind of release.
Andi, I think even we thought this was so unsafe to use and some people were in English and production eso It's been around a while and it was never it never ended up being specific to any particular project.

[6:27] So in that time frame, a lot of folks were using PEAR correct Teoh get dependencies.
PEAR was used widely, but not to install dependencies for your project.
I think PEAR was mostly used to install a couple specific tools, like PHP unit, I think at the time was commonly installed for testing purposes through PEAR,
and a few other people had figured out how to set up their own terrace server to serve their own fouls.
But one of the shortcomings of parodic then had always been the tight integration between parent, the command line utility.
To install things, PEAR the server side to the command line where you stole things from where you keep your packages and PEAR the framework or set of libraries with a very strict set of rules around how to get in there.
And so the actual PEAR framework of the libraries on PEAR that people use were very restricted.
And while I think some of them were quite widely used, it wasn't the kind of open platform that packages stood organs today for composer, where anybody could publish any of their packages for any framework for any specific project.
And so, while PEAR hot, somewhat white spread used. It had a very different kind of use.

[7:42] I guess what I'm trying to figure out, you know, So at the time was composer replacing you know, anything There was it something that people were just dealing with manually.
You think it was very much most people dealing with them manually. People downloaded supplies from somewhere copy to files the right directory.

[8:01] They copied source code off off random websites. I think PEAR was just not used for all your internal dependencies.
It was used for a couple specific things and in the wider sense, PHP just didn't have anything like that.
All right, So before we get to composer to doubt their life, I feel like we need to set the table a little bit so we can understand a little bit more about the improvements that are coming in to Dato.
I figure it might be a good opportunity.

[8:31] For a little bit of composer education and and so maybe you could tell us. How does that?
How does composer do its thing? Because you're in the drupal community, you know, before drupal. A.
We were used to getting like drupal modules via the drug sh command line language, which the drupal command line tool and it was always very quick.
It just downloaded the dependence. It downloaded the module, put it in the right thing, and it was done. And And composer clearly does a lot more than just that on and it takes longer.
And so folks are like, Well, why isn't composers fast is my old tool?
Um, and the answer is because composer does a lot more.
So can you talk a little bit about like, what is the process?
And let's just do something simple it when we do a composer, require on some dependency, there's a lot that composer does toe figure out if you know what the right version to use.
If there's any dependency, conflicts like how does that work internally from a somewhat high level picture? Let's let's go through that process.

[9:31] So I think the first thing is to break down a bit. What does a composer require?
Actually do and composer require? And now, where terms is really more a shortcut command in that it first goes in. Edits your composer to Jason file to just add new lying to require something new, and then it runs a composer update.
So the court to commands that composer really consist stuff are composer, update and composer. Install and other commands, like composer, require a composer. Remove really are just shortcuts that added the composer Jason File before then, triggering one of these other commands.
So a purpose of composer update is to take your composer.json file,
to then download metadata about packages that are available, what versions they have with requirements they have that you may need for your project and to generate a composer. Don't lock file.
So by default, it'll download this information for on packages. Don't work.
When you run a drupal project, there's usually the drupal.
I think it's packages dribbled up or regret repository for drupal packages.

[10:31] And it gets the metadata for all the packages that have listed in your require and you're required. F statements.
Eso a list of what versions are available for the authors, that kind of meta data to display the packages but also most importantly, very requirements.
And composer then uses this to do the step that we call resolving dependencies, which is to,
figure out what is the set off virgins of all these dependencies that I need to install in order to best fulfill your requirements.
That means typically, if you specify aversion range like I want a one point asterisk virgin.
We try to install the latest release off that particular package.
But if that particular package then itself has a requirement for another package, which your project also depends on but in a lower version, then that may not be compatible. So we're gonna have to install a different version.
And so this is what's dependency resolution to figure out a solution.
Teoh match all these different requirements that you have so typically an easy way to speed up Composer Oversimplify composer is actually to list more specific requirements and your composer Jason file.
That only helps so far because, of course, it also matters how specific the requirements in your libraries are because they require things and in turn, those things required.

[11:53] And if, at the same time all of those become too small, then there isn't any overlap anymore. And it becomes more difficult to even find a particular set of dependency, since not necessarily easy, to find the right path there.

[12:06] But for your own projects in your composer to Jason Infused require specific versions rather than a large range that already limits the number of versions that composer even has to look at.
Consider, while it's resolving dependencies, once it's done, that generates a composer.lock file. And that is really just a list of all the versions of all the dependencies that you have and their dependencies and their dependencies and so on.
Just a list of all these package names, their versions, the metadata and then the composer installed command actually just reached this file the lock file and downloads those packages and sticks them by default into the vendor directory in a particular project.
I should not sure how this works, and drupal, I believe drupal also has, like a custom installer, which sticks them in a different directory, which is more like where traditionally drupal margins would have gone.
Yeah, we're using. We use composer installers, right? Exactly.
So there's like a mechanism. It's kind of composer plug ins and specifically, composer installers that basic allow you to define custom directories that they get insulted.
But the key part is composer install downloads your source code, and it extracts it into the correct directory in your project.

[13:07] So that seems like the easy part, right? Like the composer the composer install seems like the easy part.
By then, everything's defined. It knows where to go to get the code. It knows where to put it up.
Computation we? That's kind of the easy part in terms of performance that's actually also typically a problem like that.
That part can take quite a while if it has to, like, download all those files, extract all those visit piles to performance wise. That, too, may take quite a bit of time.
But in terms of complexity inside of composer, it's a very simple, straightforward process.
And so this aspect also usually does not require a lot of memory because it's very much just iterating over that list of packages and taking a few steps.
So where is Yeah, I'm aware, and I've run into this sometimes where I'm doing a composer installed or even a composer create project, which I know in turn calls composer install.

[14:03] Um, you know, sometimes I hit it out of memory.
There is that that's not on the install part of it, that's on the update. Part of it is that because of all the metadata that it has toe bring down, that is a very large part of that.
So one of the things that you can imagine is that if you know, if you require and a range of reasons, we're gonna have to download all the metadata for those versions because we have to figure out what requirements they have. Which of those bridges?

[14:31] And then for each of those we have to check those requirements after Donald, all the metadata for those and so on.
So it's kind of a records of process now. The problem with that is that it's not just a recursive process because we're brother.
When you try and resolve this, it's not straightforward. You just take the highest version, and then for that one, you check again and check again. Is that because there are kind of cycles in this where one package can define a conflict with another version?
So if you take a particular version of some dependency and then later for another dependence, you pick a different version that may actually conflict with the previous decision the silver made.
And then you can install the version that you previously picked, and now you have to kind of start over on, so this process gets a bit complicated.
Additionally, composer supports keywords like replace and provide, which are very useful mechanisms that allow you to create a alternative package that replaces another one.
So if you have a dependency on one particular library, somebody else can publish one that is has a compatible a P.
I and says it replaces this one. And so if you require that one,
it still fulfils all of the all you if you're dependencies requirements of the original library because it has a compatible interface, but you're using the other implementation.

[15:51] Features like that make this whole process of figuring out which versions were compatible quite a bit more complex now in terms of memory use.
The first part is what you said. We have done all these versions and that was also fined back in 2012.
But over time, the amount of releases for each of these packages that are commonly used has just been growing and growing and growing.
So the amount of meta data that we actually have to load has been increasing over time as well.

[16:19] The next step is that in order to actually do this dependence of resolution stuff that I keep talking about, what we use there is called a sat solver or a bowling satisfy ability solver,
and that's basically a process that takes a Boolean expression like something you would stick in an if clause in PHP, which we generate from all this metadata.
And it tells us which of the variables would have to be true or false.
True meaning I have to install this particular version of that package folds, meaning they don't need that particular version of that package.

[16:54] Now the more versions are involved in this resolution process, the bigger this Boolean expression gets.
And unfortunately, some of those dependencies were kind of an exponential growth thing.
So for each version that we add, the amount of internal rules that we have to generate to represent this expression grows many times over.

[17:18] And as a result, this representation, which is then used as the input for actually running the solver, which is pretty efficient and passed, uses a huge amount of memory.
So a lot of the performance off resolving dependencies, eyes not lost, actually resolving the dependencies.
What kind of generating a memory structure which can then be used to do that.
Wow. OK, yeah, I'm following you. But that is a lot.
Yeah, it's definitely not something that you know you have to deal with on a typical drupal project.
So it seems to me that the way to increase performance and memory usage is to somehow limit the number of versions that who's metadata has to be loaded into the salver.
Yeah, that's very much one of the key things that what we looked at in inversion too.
So I think in version one what we've been doing for years now.
I mean, we keep working on performance, but it's mostly about reducing the amount of memory.
One of these particular rules takes up by a few bits by doing some kind of minute, many optimization,
trying to some Oh, you know, shave off a few bites here and there, but in composer to read, We're making some BC breaks, which allows us to make some bigger changes.
And so we can really refactor the code to allow us to do things like that to really come up with a new process that reduces the number of packages versions that are even considered.

[18:45] So that's one of the big steps that we've taken is that we re factor the code that actually does the dependency resolution to,
first download all the metadata on run kind of an optimization step on that which reduces the number of versions that we don't really have to consider as faras possible.
Already, based on the information that we have from your composer.json that we have from taking kind of like a first glance at all the dependencies, you can make some conclusions like you know that certain things do not get replaced.
You know that a particular version is not required by any of your other dependencies.
You can kind of do eat those, and you can have go through and try and reduce this amount of versions that you even have to consider and then resulting dependencies,
so that zone as you just said that seems like that's a big part of the improvements coming and composer to as faras performance and memory usage.
Um, let's move away from performance. Remember usage for a moment. What else? 10. We expecting composer to.
As far as you know, I don't want them flagship features, but kind of bigger things that folks will notice.
So I think overall or a main goal is to not have a lot of changes that users will notice, because we think we very much think of composer as this type of utility that you want to just keep working.

[20:06] You're not looking forward to big new features where you have to change your views and modify a lot.
Eso There aren't really any major new features apart from the overall improvements to performance, I think kind of apart from what I was just talking about about the internal improvements.
What users will notice just in terms off interaction is that we also work on error reporting a lot.
Eso is part of refectory in this dependency resolution. One thing that we actually worked on us, the error output that it generates when something goes wrong,
because in composer, you know, if you run into a conflict between packages, that can be pretty difficult at times to figure out exactly where that this process get wrong,
and wrong, and I think we made a big step forward in making those error messages a lot more comprehensible on.
Then there are smaller in your future is like there's a new option and for composer update that allows you to ignore specific platform packages.
So that makes it easy for you to test your project on PHP eight, for example, without removing all the requirements for extensions and changing the PHP requirements.
Um, I think these small things were certainly useful. But there's not that big thing that everybody has been waiting for.
Well, I think the performance and memories that improvements are that one big thing.

[21:27] Yes, exactly, Andi think in terms of performance, there's another thing that we haven't really talked about, which is all the changes that we did to networking.
Like I mentioned, beginning, even the installation of packages can take quite a while.
So one thing that composer to dozens paralyzes all the network requests it makes.
It makes use of http, too, in order to do a lot of requests over a single connection at the same time.
On this kind of solves the other aspect. That's been a problem.
We're downloading the metadata. Originally in the nature. Downloading the files has actually been quite so in slow in some cases, and should improve that quite a bit as well.
So have you talked about in general like what can users expect as faras performance gains?
You know, in just maybe layman's terms?
Can folks expect your an average project with Maybe, you know, 10 direct dependencies? Can folks expect, you know, composer performance to be twice as much twice as fast or we're not talking about that until there's a final release.
So the problem with that is that it's it differs so much depending on your dependencies that it's difficult to really give generic.
First eso. From what we've seen people reported so far, it's anywhere from a 20% improvement to an 80% improvement, like 80% improvement being it's five times as fast as before.

[22:52] And so it's difficult to give you a number that will make sense on your particular project. Does it Very much depends on the complexity of your dependency tree on.
And that can be simple, even if your project only requires one or two things.
If those things in turn, have complex dependencies to a have trouble giving you specific numbers on this. But I think in all cases thean improvement will be very significant.
You know, from a drupal standpoint, folks that use the drupal core recommended project template.
You know, we're starting off with I don't even know how many, maybe 30 direct, you know, third, Namdaemun at direct dependencies. But 30 dependencies just for drupal core.
Um, so I think any performance gains, they're gonna be more than welcome.

[23:42] So I think for like some other projects have seen some e u reported, you ran out of memory.
So that means you're probably ending up using at least like something like two gigabytes of memory is think like composer by default says that to 1.5 cakes.
You could definitely expect a 50% reduction in memory use.

[24:00] That's amazing. And and potentially more than that, we are so working on some of these things that were kind of hoping to even get a little bit more out of that before we do a final releasing composer to.
But even with the current version that you can already test if it composer self-update --preview, you already get huge gains like that.

[24:22] Yeah, I'm not the one thing I wanted to mention. The ability to Teoh move up to composer to with self-update --preview and then roll back to the latest version,
makes it this crazy easy to play with composer to the current Alfa E.
Think it's also something that is very risk free because it's something you just run as a test on your development machine.
Like it doesn't break your code or anything like it's just you locally check what happens.
And then you can just go back to what you had before or, like your luck files committed anyway. So you just reset it to a virginal state.
So we really appreciate anyone actually giving this a try and reporting any potential bugs that show up.
It's part of the stool released to us about the same time we do get the impression it's already extremely stable on.
It's mostly still in an Alfa release because we do want to make a couple more changes, which may potentially still break compatibility for some of the plug ins.
But that should not have any major impacts on your usage of composer on regular projects.
Is there a goal for when you'd like to get ah to Dato tagged and released.

[25:31] I don't think we have a particular timeframe in mind. I'm pretty sure it's gonna happen this year at some point still, but,
it very much depends on you know, how many problems do we still run into?
How soon can we get? The rest of those optimization is done, so there's no specific time frame that I can tell you at this point.
All right, fair enough. So let's wrap this up. I want to ask you about private packages, which is packages dot com.

[25:57] Obviously, you know packages dot org's is the canonical repository for for composer projects, but packages dot com them It goes, my private package ist and I get the feeling that,
packages dot com is what you and Jordi used to, you know, you know, fund this whole thing.
Yeah, exactly. So that's really what's made a big major development, step like composer to possible that we started private Pack A just a few years back.
A Z a solution to get a composer repository much like packages don't work, but for your internal use.

[26:36] So it's interesting for companies that rely on composer that need better availability than what they get from that.
You just don't work that want to be independent off open source developers hosting off packages.
So the way that packages that or works is actually that it only hosts the metadata, and all the downloads come from wherever the open source developer decided to host them.
And so, if you want to be sure that if that developer decides to shut down their site or something like that, you continue to be able to install your site with their latest versions that you were using.
Theun Having your own repository that narrows those packages is a great idea on private packages is a great solution, that office just that.
And through this service, which provides additional value to companies that rely on composer, we finance the development on Composer These days,
eso both Jordan and I can actually spend significant amounts of our work hours on composer because a lot of companies and the PH few world are paying for this service that we offer.

[27:39] So I'll mention, reflect pricing starts at 14 euros month, and that's for a single private repository.
So the way that it works is actually there's a base price of 49 years a month for the club plan, and then it's a no additional 14 euros a month. For if you have more than three developers as well the 14 euros a support user price.
The number of repositories that you have the number of packages is unlimited on all our plans.
So it doesn't matter how many packages you have always based This on is the number of developers that actually end up installing packages through the service because that's a much better estimate on our experience of how much,
resources we actually have to provide for your company to use the service.

[28:24] Thank you. Yeah, I was misreading that the pricing page.

[28:29] All right, and that's at packages dot com. Well, Mills, thank you so much for your time and your contributions to the open source community.
I mean, it's a wonderful tool, and I know us drupal folks are a little bit late to the party, but, um, I don't know how, um.

[28:48] Looking back at me before I was using, you know, composer with drupal eight.
Like managing all this before Composer. And now it's I don't know how we ever kind of lived without it, So thank you very much for all your contributions.
Well, thank you very much, for that was a great time being.

[29:04] Music.

[29:12] We recently made a few additions to the drupal is a podcast.
The podcasts now automatically available on YouTube if you choose to listen there on also, we've added an audio transcript which you can access at each podcast page on DrupalEasy dot com.
We'd love to hear your feedback about these and other changes You would like to see us make.
Feel free to drop its line. Just used to contact form at DrupalEasy dot com.

[29:41] Music.

 

 

 

 

Drupalcon Global Chat Chat

[29:47] I'm here with Liberator missing the last vowel Ryan price. How are you?
I am doing so good. I am so excited about drupal con Or should I say drupal chat con?

[30:01] I feel like I should just sit back and mute myself from Just let you ramble on because I feel like you're super excited about this.
You know, if you had asked me two weeks ago like what do you think is gonna happen?
I would be like, I don't know. I mean, their skin is Nobody's gonna be hugging, you know, like I'm not going to get this smile at anybody. Like I feel like there are certain things that I come to expect out of a drupal con.
It was really, like, ambivalent about this whole virtual thing. I was like, Is it gonna be good? Like I have had Ah.
For the last seven months now two small Children in my house.
So I haven't really been able to attend any of the virtual events. I think you might have been able to check out a few, including very recently drupal Camp Asheville, right?
Right. A Nashville also used the hopin platform. So it was great practice for me for this weekend after it was, you know, it's agree event in person.
And I think you're having the same feeling now that I had last week where this happened. Platform. This virtual event is not going to be Ah, I hate to say it's coming at it from a negative way, but not as bad as I thought.
I mean, let me tell us it's better than I thought it was gonna be a oh, so much better.

[31:23] Ah, yeah. So So, you know, I had I had my doubts before the event actually started. Right.
Um, I am part of a company that is one of the sponsors. We have a booth f f W.
And they were asking me to jump in and, you know, like, sort of wholesome lead conversations during the booth time,
about sort of different topics, like, you know, layout builder paragraphs.
And then there's this other tool acquia cohesion that I've gotten a certification recently. Aqua Cohesion.
So, uh, you know, I am sort of uniquely positioned as somebody who.

[32:08] Knows something about this sort of new awkward platform. But I've done some drupal eight site building stuff, and I actually haven't worked a whole whole lot with layout builder.
I've sort of like looked over a lot of people's shoulders and and watched a lot of videos and have been watching every session I can during drupal con um, So anyway, you know, I was thinking like, Well, how is this going to go?
Like I've given virtual presentations before, but it didn't really understand how sort of amazing the chat is during the drupal con here.
Um, the fact that the chat is just automatically open as soon as you join any session means that you know, you're in, you're in a session.
I was in a session yesterday with 440 people in it, and usually that means that you're sitting, you know, cheek by jowl with a bunch of other people.
There's people sitting on the floor. There's people standing in the doorway, you know, there's maybe there's an overflow room somewhere where people are trying to catch whatever the presenter is saying.
In this case, everyone has their own personal space, and they're comfortable and they're watching the presentation.
But they've also got the chat window open, and I wouldn't say that.
It's like 100% of the people are chatting. But a good percentage of people are in there asking questions, replying to each other, bringing up points and counterpoints to what the presenter is saying.

[33:37] I saw a little bit of it during the drupal are during the Dries note, which I didn't haven't actually gotten to finish watching it yet.
I've watched about the first half of it, and I got up to the point where I was able to watch a few minutes yesterday.
Ah, so so I have some thoughts there. But the the chat, the chat is the killer app of this event.

[34:05] Okay, so, uh, I was just going to have to go into the until you ran out steam there. So let me let me hop in here.
I completely agree. I think the chat is the unexpected hero of this event.
I think everybody that well, that's not really fair for me to say. But the the the meta chat or the chat about the chat in The chat from my perspective, overwhelmingly positive.
Yeah, And I guess if you don't like the chat, you're probably not gonna chat about it. So, you know, I don't know.
I haven't seen anything on slack about how the chat socks, or if not that it hasn't devolved into anything horrible. It's always been, you know, all the sessions I've been in and so has been extremely positive and helpful. And it was downright fun.
Um, that, But let's let's.

[34:57] Let's step away from the chat for a second. And so let's talk about I think, the one thing that the hopin platform doesn't have that for our community, and I don't think it's completely unique to our community. But it may be a little bit.
Is the ability to kind of quickly spinoff video chats with a group of people, right? Right can go into hop in and do a one on one video chat.
But, you know, hallway chats are always kind of cool where one or two people start talking and then two or three other people show up and being able to recreate that virtually somehow, I think would be a big win.
Um, you know, there is, like, the global event chat that's going on, and,
you tend to see you know, the folks that you know in, you know, sessions or chatting like maybe like in one of the plenary sessions or something like that.
But, you know, we're all kind of craving like this, this human contact right, because we've all been holed up for on four or five months, whatever it is now.

[36:03] And you know, while the chat is great and it. It does kind of scratch part of that bitch.
And then some of the some of the presentations where you see familiar faces.
That's also, you know, you know, is it something that's affecting the positive part of my brain and even like last night with trivia,
you know, my team and I respond up our own zoom chat, our own zoom room at the same time that we were watching the hopin Nice, you know?
So it was a bit of Ah, it was a lot like trivia night where there's just too many people talking at once. You have a table side conversation.
Yeah, but it was it was great because, you know, you got to, like, hang out and see video and talk with people that, you know, you would don't say normally only see it a drupal con, but that you probably be hanging out hanging out with at the drupal con.
Yeah, so sessions sessions are really, really interesting this year. Um.

[37:00] I was trying to explain to somebody else, like I think there are technically a few lesser the number of sessions, but not a whole lot, like they're spaced out more so like it's happening over the course of 12 hours instead of eight hours.
So maybe if the same number, but there's just fewer happening at a given time. But then there's 15 minute breaks between everything.
So it gives you a chance to, like, get up and make it coffee and, you know, do whatever sorts of things you have to do.

[37:28] You answer emails and then go back. I guarantee that most people are attending more sessions than they normally do, and because I'm gonna go back unbelieving, not unbelievably.
But I'm gonna go right back to the chat is you consider you can be in a session and still have a quote unquote hallway conversation in that chat, right?
It's like the five minutes you would have after the session is over.
You know it's happening during this session. That's really interesting.
Yeah, so I mean, literally all day yesterday, all day today. I mean, I'm doing some work and then kind of multitasking, but I always have a session going.
And if it's a session that I'm really interested in, I'm not working on watching, participating in the chat.
But I don't think there's been a a time where I've been sitting at my desk and I don't have a session open since you know DrupalCon global started. Yeah.

[38:30] So the future, the future, Yeah. I mean, I guess we're gonna keep the shortlist. Let's jump right into the future.
I definitely have some feature requests for hopin. I mean, I think you have already called out. One of them is, like, sort of like an ad hoc conversation.
Um

[38:48] You know, look, coming from somebody who's watched a couple of the things that happened at the at the presenter booths, there is some of that sort of organic conversation stuff going on there.
A few of the the sponsors have sort of figured out that,
the killer app for hopin in the sponsor area is being able to do group conversations and inviting people to join via video,
and, you know, ask a couple of questions or give a couple of impressions and then sign off again.
So, um, I have seen some of that going on, but, you know, not everyone is always comfortable in sort of like sponsor space to to have those kinds of conversations.
You know, sometimes you want to talk about something private or something very specific to your business, and you can't, like, edit out the details to make it suitable for public consumption.
Um, but so yeah, that's sort of like group video chat or group video chat space or something would be interesting.
Um, I think a lot of people have gotten spoiled by the chat on apps like Slack and you know, teams and discourse and all that kind of stuff like that.
Eso you know, maybe more robust chat features would be nice at some point, but, you know, like, really, what we've got right now is working pretty well.

[40:16] Um but I would like to see I would like to see in person drupal events come back.
I still think there's a place for those, but I would also like to see this. This exact event happened at least once a year.
I would I would keep paying money to do this.

[40:36] Exactly. Yeah, I completely agree. This this seems to me and I've seen discussions.
I think it was during the Dries, the Q and A with Dries earlier today.
I've seen discussions about I think someone asked Reese if this is gonna become like an annual thing on a you know, he obviously no one knows. So he's not sure.
But the chat in the chancellor's discussion Well, our future drupal in person drupal cons to those become hybrid events.
Where there in person. But then they're still broadcast via hopin so that people who can't attend in person can attend via happen.
Or should it be a purely virtual event where no one's there? No one is. You know, no one's in person anywhere.
Um, personally, for me, just on my my My initial reaction to that is, I think it should be purely virtual.

[41:33] In addition, this should be in addition to a drupal con North America and or a drupal con Europe that that's my personal feeling as well.
Yeah, I don't think a hybrid is gonna achieve. I think it's too many moving parts well, and it creates a second class citizen, either.
The online attendees are first class or the in person attendees or first class. I'm assuming it would end up being the weighted towards the in person attendees, right if there were a hybrid.
But you know, if if hoping is the platform and it's used the way to being used right now, someone's gonna get left out of the event by not being on one or the other.

[42:12] Um, and there is there. Is this us a good amount of overhead of being at a live event that hop in just sort of like completely delete? So, you know, like you don't have to walk from room to room.
You're not have to figure out where lunches, you know, if you've missed the time for coffee or, you know, if you need to get up toe, do something urgent during a session like,
you're not being rude and like tripping over people like there's there's so many things about doing a virtual event like I think virtual events should stay.
I think that having them happen on the global scale is also a really good thing.
You know, maybe some of the more like subject specific events like D for D or, um, Gove camp Or, uh, what are some of the other?

[43:03] What's the one that happened in Europe?

[43:06] Ah, designer days. Is that what it's called? Drupal Camp?
London is a big event, right? But some, some of them more like subject specific ones. I think those subject specific things would really really benefit from a virtual platform versus an in person one day.
Yeah, so there, you know, there have been some that are, like more design specific or more, um, you know, different different sorts of, like disciplines or different, sort of like micro communities, like a nonprofit summit.
Something like that would be great as a virtual event.
So, Ryan, let's wrap up this discussion with a bit from the dress note.
Yeah, so as Dries is up to do, he likes to use the dress note as an opportunity to set out a vision for the next year or so for the drupal project.
And this year was no different, and he identified five initiatives that he would like to see the community take up.
So what do you tell us about those five initiatives on DA You know what? Your thoughts? Sure.

[44:10] So I'm just really quickly I'll read through the list. He talked about having sort of like a front end javascript that could deal with the menu system.
Um, making automated updates, polished and working,
Um, making sure that we get a new front end theme so that the out of the box experience is, you know,
as good as can be and sort of, like includes all of modern bells and whistles and making the out of the box experience better.
So sort of like those two, I guess, sort of go a little bit hand in hand.
And then, um, you sort of like General drupal 10 readiness.

[44:52] Right. So let's talk about the Java script menu thing.

[44:58] This is one of those ones that as soon as you bring it up, people start pulling out there. They're six shooters, and they're, like, ready to talk, right?

[45:07] What he said to me at least made a lot of sense because I am not a JavaScript front end developer.
I have a passing knowledge at best, but I am aware that there was an effort.
There has been an effort to react if I for lack of a better verb, the back end of drupal.
Um, but it turned out that it was this project that just kept on growing and growing, and it was difficult to kind of wrap your your arms around.
So what'd Dries you know, It doesn't It's not that it sounds like, But what he basically stated was, we need to redefine the scope we And so he proposes that the initiative be limited to,
you know, providing um, the necessary, uh,
Ap eyes so that different job script frameworks and I don't find both reacting view can be used.
Um and then he and this was kind of surprised to me.
I don't know if it was surprised folks who, you know, build his job script front ends.

[46:11] But he I don't find the menu system as this is a particular pain point is, you know, exposing menus and everything goes along with menus to a front end to job script front end.
So he said, Well, let's let's start there Let's limit this to being able to expose menus along with you know, all the access control, Andi.
Everything that goes along with it to a p I that both react and view can't consent.

[46:40] So I thought that was a pretty smart way of going about it.
You know, when a project gets, you know, when a problem becomes too big, you have to break it up into smaller chunks and knowing that there there have been just a ton of discussion, you know, in the past about angular or react what we use.
And he's kind of deciding that not really deciding, but proposing that Let's not choose.
Let's just make sure it works well with, you know, multiple, any identified, you know, reacted in view is a good place to start.
Did you kind of was your take away? Kind of the same is what I just said, William and and this Some of these is going to be more like what my reaction is to the headline than the whole article, because I haven't gotten to finish watching it yet.

[47:24] But I think menu makes a lot of sense because if you look at some of the other systems that we have in drupal, um,
you know, like, for example, content based stuff, that's that's an area where you could really diverge really quickly and even just in sort of like what currently popular, like no.
Two sites are building their content out the same, you know, and and a lot of the things that are doing a decoupled model.

[47:56] You know, that gets really complicated really quickly. But if you are gonna use drupal is menu system.

[48:03] Not a lot of other things interact with drupal its menu system, like it is a fairly stand alone system.
But it has like really deep hooks into drupal, like you said, like access control and, you know, being able to show different menu items for different users and different routes for different users and different roles.
And right. One of the things that Drees mentioned was that because it's a particularly particularly thorny issue, solving that is going to unlock a lot of other things,
I can then more easily be made available to front end systems.

[48:42] And it is one thing that you know pretty much any website needs.
Like you know, you could make a case. We're like, Well, what about doing something around users and user profiles?
It's like there are a large number of websites that don't want users to log in or if they do let users log in. Maybe they use a totally different system for logging in, so it doesn't really make a whole lot of sense to, like, make that the first thing that you tackle.
You need to be like OK, well, what about blocks? I mean, I think for a little while talking about the admin interface for blocks was, you know, on the on the table.
But then Now that we have something like layout Builder is like, Well, now people are going to be doing blocks in a totally different way than they have been for the last almost 20 years, right?
So it's like there's a lot of there's a lot of yes, but with those other things.
But with menu not to say there are no challenges, but I think it's a good It's a good, complete problem that has boundaries that has boundaries. Exactly.
All right. I think this is a good place to wrap things up for now. Sure.
So Ah, let's do that. And then let's will record another one of these after DrupalCon global ends, and we'll get this one out just as soon as we can.
So thanks a lot for your time, Mr Price. Thank you, Mr Mike.

[50:03] Music.

[50:10] Thanks for listening. If you like what you heard on the podcast, you can only subscribe to our podcast on iTunes drupal play or Miro.
If you're just casual listener, you can always check us out on both stitcher And now on YouTube.
If you have an idea for topic or of future guest, please drop us a line at drupal.
Easy dot com slash contact or leave us a voicemail in the US area. Code. 3213962340 Thanks for listening.