 It's now 15.45. I think we should start our session. Welcome. This is the core conversation about composer and triple eight and My name is Florian Weber. I am a core contributor and maintain the triple packages and the triple composer template on GitHub and I work at uber bit My name is Tobias Stöckler. I am also a core contributor and work a little bit on the composer stuff and otherwise I maintain the shortcut module and the config Translation module for Drupal 8 and I work for Erdfisch So the first thing we really wanted to point out that even though us two are standing here the whole Getting composer to work with Drupal is not just Not just a work of us too, but really like a team effort of a whole bunch of other people So yeah, that's sort of what we wanted to point out even though we're standing here We're sort of representative for Everyone else that's been really putting in a lot of effort so far. Some of them are here and So It's our agenda today So we want to discuss a few things at first how we currently use triple core a composer in triple core How we want to make it How we want to support Contrib modules with the composer dependencies and how we could enable third-party dependencies and also how we could expose Contributed modules on triple or two packages or our own implementation of packages So We don't that's a core conversation That's why we don't discuss what is composer or what we ought to current state of composer in triple core There are two great blog posts about how we currently use composer one is from boyans and the other one is from from Tim I You should read it if you have any question in detail and there are it's a great introduction into the topic Currently That's that's our goals. So we want that composer supports Core development so that we easy could add new dependencies and that's not Hustle that we have a huge vendor directory in our composer in our triple project We want to support third-party modules Contrib modules with composer dependencies and an example here is the address module or MS in SDK Also the triple upgrade a module. These are all contra modules which contain composer dependencies and it's currently a hacky way how to get them into or play nice with the rest of the core dependencies and Also, we want to have support Composer create project command. That's just Standard way how to instantiate a new composer project and that you can all manage all dependencies with this project and Of course, we are triple and that's why it's not that easy for us because we have many different Groups of people so we have to support different needs and that's the main I think that's the root cause why it's currently so difficult to do composer right in triple project and client projects and Every stuff so we have to support core development So that means test bot packaging We have to support the site builder use case. That's a person Who's not familiar with composer and it's a hard requirement for us that we don't need composer to Work with Drupal so it means you can download Drupal and start working And you may need composer if you want to use a contract module which had a need supposer a composer and of course we want to Support the new kind of workflow where we can manage every single dependency in our project with composer And that's basically how other PHP projects currently work And now we are recording the video What's the current state of composer in core? And maybe it'll be as long to talk about it Yeah, so this is this is basically just a clean check out of Drupal 8x which I'm proving right here And I'm just doing a composer install So this is yeah, so this is what you get If you just do it with Drupal and so this is something that we really want to support because even though It may or may not be explicitly documented to do this This is what people will do because they download Drupal. They see a composer that Jason So they run composer install because they think it'll work because that's how everything else works or every other project that uses composer But as you now see it's actually really weird what happens because now Mm-hmm Yeah, okay So now what's actually happened is we have a huge diff in Our project because composer has now downloaded the beta version of the core directory Because that's the latest release of of Drupal So, okay, let me just stop that maybe. Yeah, so let me just talk about that for a second So because we've cloned Drupal core with git we have the latest code in the repository But since we've installed composer or we've done a composer install Composer fetches the core the Drupal core a Drupal slash core package and the latest version is the Beta 15 so we actually download the beta 15 into our latest repo, which is really weird and messed up and So we have this diff so that's one of the problems we want to avoid the second problem is you see I did the LS command and you see that composer actually downloaded the Download all the third-party dependencies in a vendor directory So it's not a core vendor but in vendor which is Stand like which is standard and how other PHP projects do it but now we have them in core vendor and in vendor so That's also really messed up And then the third thing I'm going to do is so Since we now have them in both places you could think I can just remove them from core vendor and be fine But that's actually also not the case. So if you do that Like just remove all the core vendor stuff. We still have it in the top level vendor and then for instance try Dress site install What's gonna happen is because we have the autoload PHP? That still references the core vendor file and since it's not Like no longer gone no longer there. It's yeah, it's just not gonna work So we see that there's a lot of things that just don't work and are just Messed up with the current process Yeah, and so we want to propose a way to fix a lot of those things So that's that's the slide so that our current problems the core directory is in the repository it's committed and if you download and compose a Replaces triple core. We can't manage external dependencies in our root composer Jason The autoload PHP needs to be updated also the git ignore needs File needs to be updated because it's just a huge diff in the mess. So we try to do just a simple replace triple core in the root composer Jason this means This repository contains our other composer for the repository and if the dependency is first Fulfilled it means that we just would skip download composer J triple slash core, but it doesn't work because we Also would lose our symphony and third-party dependencies that are inside the triple slash core package There's also a big issue on it. It's To solve this That the root composer Jason is actually working It's called make the composer root composer Jason a working example and the currently workaround for that is that we have triple project template on GitHub because github integrates nice with these packages and then we get always the up-to-date release on it and it Contains a few other features like the vendor director is not in the document route It has a pre-configured Composer installers and a few other things So if you currently want to use it then you should check out this project, but because I think it's the best way to do composer Currently in triple core, but we want to bring this or parts of this to the triple core Project that we all can benefit from it and that we get a really nice standard solution So we had a few discussions discussions before in triple con LA and other triple cons and we tried a Few different solutions. So we tried to approach with multiple vendor directories that we have one Vendor directory in the root of our project where we could maintain custom dependencies and that we have a core slash vendor directory where we have all core Dependencies, but actually the it's not going to work because composer needs a single vendor Directory with all custom dependencies. So a few days ago actually and we found or discovered a new solution it's related with to the Composer merge plug-in. That's a composer plug-in that works similar to composer manager But actually on the composer level and it's not their external Dependent or not a triple specific dependency a Composer merge plug-in allows us to merge multiple Composer jasons into one single composer jason. It would mean that we have an Include statement in the root composer jason and this could actually include the dependencies from core slash composer jason and We could also include custom dependencies from contra modules with this approach So that's our did could be our new composit jason And it looks like this So we have triple triple or that's the standard We added it as a requirement the Viki media composer merge plug-in. It has already a stable release But I did some development. That's why it's currently a deaf master Then we replace the triple core That means the triple triple project contains already triple core. So we don't have to redownload it and Here's the magic. That's the extra configuration for the merge plug-in It would mean it merges all requirements and require deaf statement Require deaf statements from core composer jason on runtime in our root composer jason And they are all ready installed afterwards and it also can And wildcards so it means it would look in the contra more folder for all dependencies from contra mod For contra modules and themes so we could extend it to themes and install profiles and so on and that would is Would work for core development because we can't split currently our core Directory from Drupal Drupal from the triple project because then it's very hard to test and to get or our workflow because right because then we We still need to do to provide Tables for site builders and with this approach the site builder could actually download standard modules and If they don't have a composer dependency It's not required to run Composer install It just works and if it if the module has Composer dependencies and it just would work with Composer install But it would be automatically discovered so and triple core could be updated without Composer And that's was one big security concern for people who are not familiar with Composer Yeah, and that's this just addition to support custom Dependency cast contra modules to require them we are Composer, but it's a different up issue and it's not related to the merge plugin And there's also a other solution But we hadn't hadn't time to explore it in depth because we discovered it just a few days ago and we are currently evaluating both but As it currently looks like we would prefer solution one because it supports the site builder and use case and it works already And now we have also a video with the decomposer merge plugin So here I'm now basically The says the start is the beginning so I have a clean Drupal 8 Install with the same commit and now I'm going to apply One of the patches from the issue that we linked earlier So Webflow already basically rolled everything he just showed the The changes to the Composer JSON into a patch which we can see now So we upload he updates the autoload PHP and then we see the changes to the Composer JSON Which is basically exactly what what he just showed in the gist You know that should be pretty much it and now I'm going to run Composer install And we're going to see Basically that almost all of the weirdness has gone away and it mostly just works sort of to prove To prove that this is actually working Right, so now I'm going to do a good status. We see that Composer now is not at all touched the core directory So it's left that completely alone It's just has added the vendor directory and the composer log file So we could add that to the repo for now as well and you can also see now that you can just Go ahead and do the drush site install because we've updated the autoload PHP And it now finds the directories properly in the root vendor so this is really sort of a Standard workflow for anyone is used to Composer He just clones the so assuming this patch would would go into a toro.x The the workflow really could be for people to just clone the repository and run Composer install in the root and They could just work fine with it like with any other Composer enabled project Core developers because the core directory is left untouched core developers are also sort of supported and you can roll patches and everything Yeah, so this is something that we feel sort of combines the best of all worlds and It yeah, as you can see it's it mostly just works Yeah, and Currently because now we know that RC1 is on the table We want to get it in before RC1. So we have a few weeks To get it in all other issues are related to Composer our follow-ups And I think it's not really necessary to get them in afterwards But it would be even our Composer implementation would be even cleaner with them, but it will work without them too So these are the possible follow-ups and because we don't have to support Our different Composer works workflows anymore. We could remove again autoload PHP in our root and directory because Even if you use a Composer driven workflow, it's it's would be in vendor slash autoload And if you don't use Composer, it's still in vendor slash autoload. So it's not a hard require when anymore we could run Composer install and triple ci and during the packaging and it would mean we could roll Very small Composer related patches and add dependencies because we could remove our Vendor directory in core completely and add it to our gdignore. So that's basically the end goal It would make triple lighter and everything would still work top balls would work Triple ci would work Composer driven development would work Yes Yeah, it's it's it's it's just related to core because Everything else is or for distributions because a distribution Would have multiple Modules in it then the merge Plug-in would also work because they are in there and then we get all dependencies for these and could just distribute them in one distribution um Yes Mike Yeah, sorry, I missed the first question So for your site product like your site specific product you would not touch the A root Composer json file you would put it in some kind of like your own distribution or something like that or no You can touch the root Composer json because it doesn't contain any Composer Or triple core dependencies because they are still in core slash Composer json Because we merge it and on runtime it contains just your own dependencies and it's very similar to htxs or So I see sure you have you have to merge it during updates, but it's highly unlikely That we Have to touch it during triple a development cycle. Cool. Thanks Any other questions so far Yeah, sure Yeah, you say you you're merging the Composer json files But if instead you would we would create a Composer json in the root Before downloading anything and then you run Composer and it downloads trooper and other stuff And then it automatically has the dependencies of its sub-packages So then it wouldn't have to merge the Composer json or does it is that not a good idea? Maybe it's a good idea. We have to explore it But I think we thought about it already because we want the Composer merge plugin is still a little bit of a hack for People who are not familiar with Composer But we also want to support the real Composer driven development And that's why we need a subtree split for triple slash core and that's why we should Put the dependencies into the triple slash core directory to support this use case Yes Yeah The concern was Mainly that's this triple core should be updateable without Composer Or we can use Composer a triple core without Composer But if you if you use this workflow without Composer, then you wouldn't have this root Composer json. Now would you? We still would have a Composer root Composer json. Yes, and also the outer outer loader doesn't Really fit all together, but we can discuss it later Maybe in depth though So this these are our possible follow-ups and we could get them in any during RC phase maybe we should have discussed this with the core developers But it also a little bit depends on triple c and our packaging scripts But it's it's then it's already compatible and I would not consider it as as a api change because All files are still in the right place Yeah, I just wanted to point out on triple ci already does a Composer install. Yeah, so that's that part's done. Cool About a month ago Yeah, so let's Well, so the thing this would sort of change and we talked to talk to Neil yesterday about this But that was sort of before or in between we discovered this new thing so What Drupal ci currently does is that it runs a Composer install in the core directory because that's where all the dependencies on like symphony and everything else is And what this would allow us or what this would enable Is actually to run a Composer install in the root of Drupal itself Yeah, so that's also because we have that issue for Running the Composer install on packaging So that's sort of like Well, the current patch matches Drupal ci and that it runs it in the core directory But we might want to like discuss the relation to this issue Because that would change it to Running Composer install in the root. So it might make sense to sort of like yeah, we should sort of discuss Whether it makes sense to then support a postpone the packaging issue on this And try to get this in as fast as possible before rc and then Like make packaging directly run Composer install on the root um Yeah, that's something we we should figure out Yeah, right, right It's sort of yeah, it's sort of like a chicken and egg thing like we want to get this in as fast as possible, but um Yeah, yeah, we should right Yeah, okay now we solved how we gonna use Drupal With Composer in core and it all works, but here's another big issue and that's related to our packages or that we host all Modules on packages so packages is a Composer repository and it contains all metadata about it would contain all metadata about Composer packages it means Drupal module themes install profile distribution trash extensions everything and We have there are two options One is the first option. We just push everything to packages.org but It has a few Downsides because it would require that every repository we are want to publish there has a Composer jason That's currently not the case for contrip because I think we should have Composer jason in every single module because there's no real benefit if you want to Composer driven development and you only can require modules that have Composer dependencies every module should There should be there otherwise there's no real benefit and It would also require that we apply semantic versioning to triple contract projects and they are Both are long outstanding issues. So I think it's not feasible that we get it for troup late. Maybe we can take a new Um try for triple nine, but I think for triple eight. It's off the table or I guess so And the second option is what we already implemented. It's a triple specific packages packages and and This could have some more logic It could accept repositories that doesn't contain a Composer jason because it can translate or generate the Composer jason out of the triple info files and we do it already And it would also work with our current versioning scheme because we could translate the versions to assemble like versioning system um triple packages is already up and running and we had a 170 30 Thousand installation last month. So that's a lot I guess and we started early 2015 and it's a steep growth since then um There are already issues for the for this and yeah That's um, there's an uh another approach so that we could change our versioning scheme to Not a three digit versioning number that we we could use four digit versioning numbers and Composer supports it internally, but never has tried it already because It's I don't know why it's in Composer, but yeah, nobody uses it. So it's I think we will run into issues and they're already we discovered already a few issues like the tilt Operator and the carrot operator doesn't really work because it it runs It's required to have three digit version numbers for it and we would have four It means the meaning of tilt and carrot operators is completely different and I think it's very hard to Um to explain this to all developers that our Composer requirements work different than anybody else Yeah, I work around for our branches as the branch alias So we could um convert our a dot x minus a dot x branch to a somewhere like um constrained Yeah, that's basically our core conversation or our intro in the core conversation and I think we Discuss the usage in core a lot, but we should discuss the packages implementation as well So we take questions or So if i'm understanding your proposal correctly for handling core We'll still have core vendor in the repository And therefore in the tarball and if we run Yeah, if we do run Composer install in the in the Drupal root We'll end up with the second vendor which it gets used instead of no We would review this patch also moves the vendor from core slash vendor to the root again Okay, so what's in the repository would be core slash composer dot jason? Yes Without a lock file with that with no lock with with no lock file. Yeah, okay, and then There'd be a The top level vendor directory that is in the repository. Yes that is the result of that. Yeah And so then if I want to do a proper Composer workflow for For my sites, then I mean I have to take that back out of the repository, you know, you just Modify the root Composer jason and remove the merge plugin because if you want to do proper Composer development You would use the subj split with triple slash core Because so then I Drupals your Drupal slash core would end up in vendor No, it would end up in slash core because we have the Composer installers and the triple core project has type triple my triple minus core hyphen core and it would A Composer would display it automatically into the right directory Okay, so it guys what I'm concerned about and it sounds like this isn't a concern I just want to verify if there's multiple copies of large swaths of code I know from experience that thoroughly confuses my IDE and half of it doesn't work then So that's one thing I want to avoid and the other is if I'm If I download Drupal core and then start building on top of it and want to use Composer with it I then want to not have Any vendor in the repository There will be no vendor in Okay, a single vendor in the root and even that we if we go do the follow-ups we could remove that Completely because we can do it. We can automate it Automated in triple zion our patching packaging scripts. Okay, so at least in the interim I in my site I download Drupal. I then need to You know remove that the vendor or delete vendor then do a Composer install to regenerate it and not put the new one into the My my own repository. Yeah, okay, but it's doable then but okay for example if you would Start with a git clone then you don't have to delete anything because the git clone would be contained a vendor directory So you can just start building Okay Okay That sounds like the least bad plan I've heard so far and this is saga. So thank you Yeah, so so just one additional note to your point to the like Drupal core downloading into the Drupal directory That is actually exactly what happened in the first video when I just like when you type composer install right now in 8.0.x Um, that's actually what happens because we have the dependency on the composer installers plugin in the root composer jason And on Drupal core So what actually happens is it fetches the Drupal core package from Uh from packages and it completely wipes the the core directory that's there in git and puts the package there That's why we had the the ugly um git diff there. So that that that's actually what what happens already right now And that's what we're trying to avoid because we don't want like if The core directory is there in git. We don't want the composer to touch it But if it's not we want it to and so you know, we need to sort of have both No, I just uh wanted to ask a little bit about the semantic versioning for um For working with packages. I mean it seems like the only way you could work Directly with packages as is is to abandon the relationship to the core version Otherwise, we need to put some sort of facade Up where we deliver the json either via the Drupal packages or something at Drupal org, right? Yeah, that's right it it would Or yeah anything with if you want to keep our versioning system Well, then we have to implement some kind of new code and packages that it will work with uh different our new versioning theme But that's highly unlikely that we get it in and and and if we wanted to have Composer json in all the modules that don't have a composer dependency We either have to add a commit to them or we could add that into the packaging scripts Or we could have that as part of the We would it's because the packages reads the git directory git repository directly We need to have it in There right if packages is serving the json if we if we serve the json ourselves as a service just like packages then We don't have we could generate it. Yeah, it's okay, but we would also have to read the contrip Repositories because the repositories might contain a composer json So we can't rely just on our dribble.org database which tracks all the module releases and dependencies We have to do more than that Yeah, the other option there is what we we're talking about in la which is just Modules that don't have a composer json aren't installable via composer and go file a patch Yeah, and then that will just work its way through probably fairly quickly given that There will be a number of very high level modules very large modules that do require composer Uh for various things they already do and so the the evolutionary pressure would take care of that for us very quickly I think so that I don't find the argument that we would need to Push you know composer json files into every module a compelling reasons and not use packages as the distributor That's easily solved by just social pressure within six months Uh, you know some of the other arguments around changing our versioning Uh are compelling only because we've been talking about it for a year and still haven't done anything But I don't think the the press the requirement for the composer json is not a compelling argument Yeah, we could try to remove the Our the triple versioning version number from our version number And manage everything with composer And do like a triple core requirement in every composer json it would work, but Yeah, it's it's a huge change and it takes a Yeah, and there's like there's also like a Like a practical problem with that so that would be like the first The first scheme up there so we lose the seven or the eight completely so something like Current like eight dot x One dot x would be or or eight dot x one dot o would be one dot o Dot o so we get the added patch level from semantic versioning But the problem with that is actually that uh for drupal modules like a lot of the modules Are maintained in seven and in eight at the same time And so if you have like a two dot x which has a dependency on drupal seven because it's a drupal seven module And a three dot x is the drupal eight module Because it so it has a dependency on drupal eight Well, then like a year later drupal seven is still around and you decide to add like new features to your seven version um Then that Like you really have no semantic version for that because if it's like a if you want to break the api in seven Like your seven module is two dot x and you break the api so you have to push the major version So that makes it three dot x but three dot x is already the eight module So should it be four dot x or like two point five dot x or like That's sort of something that's unique to drupal because Like modules are just really really strongly bound to the core version It's just not it's different than with other projects. I guess Yeah, two ideas about this semantic version. I don't know if that's a good idea But first would be to make the core version part of the module or the package name So it would be d eight views all right views. Okay. It's not core, but uh, it would be d seven something and deny something And the other idea would be No, that's something I forgot there um and then Generally they to to publish something on drupal orc and then have some automated process to put it on packages Or to publish something on github and then have some automated process to get it on packages or on drupal orc or something With this kind of script or automated process. We could solve a lot of problems I think so some of this you already suggested but they can't go in different directions And so someone who wants to have everything was composed and puts a composer jason in their module We could still have something that gets this on drupal orc, maybe I'm not sure but And someone who wants to do old school and to sort of drupal orc without composer jason then We could have something that adds a composer jason automatically. I don't think that's I think that's better than uh forcing everyone or more realistic maybe Yeah, well and um So not directly an answer but more like sort of in in the same context On packages the drupal namespace is currently owned by drees So no one can just like publish Like drupal slash my cool module on packages And there are already a couple modules on packages that Do exist but they like preceded the fact that drees now owns the namespace So we could actually have both so we could have like an automatic integration with drupal.org that pushes the Modules to packages under like drupal slash token and drupal slash address or whatever And then if I just want to push some module to github because I don't want to go through drupal orc or whatever I can still push it to packages on my namespace or in my company namespace or whatever And then still use it with the composer workflow. So we we could actually have all the flexibility But still keep drupal.org sort of as a canonical source for For our modules and and still have that integrate with packages. So Yeah Yeah, and I remember the other idea that was to have one package that contains different core versions But in different subfolders maybe and could even contain a wordpress extension or something So the download this is uh Was composer and then drupal ultimately finds the right folder where they for the correct core version and a lot of the classes might Be shared between the different extension things But um, then there's some specific stuff that is for the specific core version of drupal Oh, you mean like for a module to have like Both versions of a contributed module in the same repo for the same version So you download like 2.x of token and it both has like a d7 module and a d8 module. Is that what you're proposing? Yeah, that's an idea Okay, let's just say Yeah, yeah, I think that would solve the semantic versioning issue. I'm Still not sure that's like, I mean that's maybe something we have to discuss. That's not something like that's something I would Advise strongly against But yeah, that's maybe a discussion we should have nonetheless So just a small reminder that tim has created a buff on thursday at 1145 that we can use to Continue the discussion. I mean as far as I'm concerned, we have solved the problem of the core workflow using composer We just need to commit the patch and finish it But the other problem that we haven't solved and we need to use drupal con to solve is the problem of drupal packages versus packages And larry and others had a very strong argument initially about pushing everything to packages Mostly for ideological reasons But there has also been strong opposition since then for more practical reasons and we should try and resolve those I honestly don't have a horse in that race But we should finish drupal con with an answer to that and if we decide we want to keep using Drupal packages, then we need a follow-up to actually add that repository to our root composer json file Yeah, I totally agree. I mean we we Too talked a lot about that as well in like in the preparation preparation for the session And so I think we at least we too agree that like in the long run Actually pushing everything to packages is sort of where we want to be at some point with everything having Composer json and somehow falling semantic versioning But especially due to the versioning issue. Um, that's just not something we can do in The matter of months, I guess um And so Sort of where we landed at at at our discussion is that the there's really no way around Some some drupal specific version of a packages in at least the medium term So But yeah, that's of course also up to discussion. I guess So are there any other questions comments? So slightly unrelated observation um, actually Earlier I was talking with fago about a completely unrelated topic that is being able to replace some core classes with other classes by Developing them in contrib and then later when they are mature enough moving them to core And he was bringing up the fact that we would need somehow to tie that to the actual versions of core And so being able to somehow reflect that version in the version of the contrib module because otherwise We wouldn't be able to cleanly move them in core and have everything working smoothly so I think we could have an argument for resolve the Semantic versioning issue for contrib aside from packages and our side from composers So probably we should bring them up anyway Can I ask you to come back up? I'm not quite sure I understand What you're saying there so developing a new version of some core service in contrib You can swap that in From a contrib module very easily already At some point we can move that into core cool. No problem. I'm not sure how versioning gets into this question well, I might have Missed some details because this is a discussion. We had a few minutes ago So I might not have it might not have reported it correctly. But actually the idea was we were talking about replacing Actually continent to the basis or not Okay, so basically the idea was that There may be many modules that are already extending the base class that in is in core And we want to move the new base class in core And so we would need to do some fancy stuff to make sure that we are not breaking everything in the process That's why gigantic bass classes are a bad architectural pattern in the first place. That's the answer to that I I don't know what I don't know how composer would help with that I was not talking about composer. I was I was talking about being able able to somehow link the core Versions which is semantic with The contrib version which may not be semantic We would be addressing many of the same problem that were already brought up So are you talking about like contrib modules that require certain core versions? Yeah, that's already supported. I believe Okay, well, that's how do we version How do we version the core and contrib module in a way that it reflects the fact that somehow It's linked to a specific core semantic version the Yeah, the diversion requirements Or the requirements property in the module info file already supports ranges So it can specify this version requires this range of core versions that that already works And you can do the same thing composer if you wanted to like I don't know which one you'd want to be using at that point Okay, I will think about this. I mean I'm aware about that I'm probably I need to talk about that a bit more with but I was just point out that There may be other good reasons for for thinking about Uh semantic versioning aside from composer In contrib okay, so sorry about that the the dependency on like the version specific dependency on core Only works through like the work around like to specify Dependency on system module and then specifying the version there and that actually does not Support semantic versioning so you can just put in like system and then uh, like greater than 7.16 or whatever or 8.3? But I'm not sure that you can actually put in like greater than 8.3.3 I'm actually like 85 percent sure that's doesn't work, but I haven't checked in a while. So Yeah, that's true. It doesn't it doesn't actually do that Yeah Um, I kind of want to bring up a separate composer versioning issue that um, I'm seeing from from like a testing perspective And in the test spots and that's once we cut a actual release and it's like 8.0.0 or 8.0.1 Um, I'm suggesting that the composer json file for core Does has a range operator for the maximum version that was available at the time we cut that release Because there's been times when patch releases of dependencies have broken the testing infrastructure And so what would happen is if we are testing against something and then Somebody else commits a patch to their Um to their dependency project it could break what what we have released and so we could say well drooplates Compatible with these versions, but it's not And so I just was wondering how people thought about that if if that's a good idea or if There's a reason against range operators to say, you know, this is the max version when we cut the release that we should accept or thoughts on that Composer lock will only work for the entire project. You can't lock Core you you have a lock for the whole project. So If we're inheriting composers json from below then there's only one lock file For core itself, I would be perfectly fine not bothering with the range just saying this is the exact patch version that Core is going to use we bumped that in the next point release in the next uh You know patch release of droopl if like there's a bug fix or security fix or something like that But for core itself, I'm totally fine. Just pinning it to you know guzzles 6.0 point 2 and that's the exact Version we're going to use no ranges at all. I think that's totally fine for droopl So in the light of like the earlier issue that would basically mean because now we have the core composer lock So that would basically mean Remove that and instead have a composer lock in the root next to the root composer Jason Or that well, yeah or sure Yeah, and I was just suggesting a range just in case there was a Contrib module it was like I need guzzle 6.0.2 And core Upgrades on the next patch release and it wouldn't work just to be able to say well it still works with these below But here's the max release Yeah I mean in theory that's like why semantic versioning exists So the theory would be that you can like we would specify the first two operators and then Get like the patch level releases because there shouldn't be any breakage But right, so I'm not sure that's like a separate discussion how how much trust we want to put in that And I would totally be fine just locking down the version altogether. I mean that's I remember there was a question sometime Discussion about if a culture module wants to depend on something from composer It's third party library It would put that in the composer jason, but then you have maybe modules and subfolders of the module And now the question is this is the dependency of the module package or of the module itself when it's enabled And I think it will be of the package. I just want to To clarify that again So when you download the pack module package, then you have the dependency Yeah, that's and not when you enable the module. I think we we could try to support Composer jasons in sub projects But it's just a new kind of warms. We are open And composer it's always package based and if you want to have Ship this Sub module separate then you should have You need to have a subtree split, but composer doesn't support repositories with multiple Jason files. It just doesn't work. It's it's part of the main module because it's high The chance is very high that you if you use the sub module that you all also Use the other module. So I guess it's okay To make it in the root of the project Yeah, I was just thinking about some others have that is like a suit of modules and only one sub module Won't depend on a specific composer third party thing And then we have two options that the one option is just to make the entire package depend on that The option would be that you have to manually add this to your root composer jason And then only then you can enable this sub module For example, we we could add the composer jason to the sub module And then you just use the composer merge plugin to use to merge in this specific module When you need it. Yeah, but then the composer merge plugin would need Would other composer build thing would need to know which module are going to enable and I thought maybe it's easier to just Then you have to manually add it to the root composer jason and only then you can enable the sub module No Better alternative, please just stop putting multiple modules in the same package. Just don't do it It made sense about seven years ago. It doesn't anymore. Just stop And there there's extremely few use cases for it and causes way too many problems. If we don't do that, this whole problem goes away. Yeah The ui modules To be perfectly honest, I think there's maybe four in all of Drupal that have a legitimate reason to have one That's it And those can just go into a separate actual module at that point. I think that's fine