WEBVTT 00:00.000 --> 00:12.000 So, our next speaker is David Wujis, I hope you're not such a wrecky. 00:12.000 --> 00:13.000 Good morning. 00:13.000 --> 00:16.000 He's going to talk about parts of the monorepers. 00:16.000 --> 00:18.000 So, give him a warm welcome. 00:18.000 --> 00:24.000 Okay, do you hear me? 00:24.000 --> 00:25.000 Good. 00:25.000 --> 00:26.000 Good. 00:26.000 --> 00:30.000 Okay, welcome to this session about Python monorepers, 00:30.000 --> 00:33.000 and the pololith developer experience. 00:33.000 --> 00:35.000 So, my name is David Wujis. 00:35.000 --> 00:41.000 I'm a developer, and I live and work in Stockholm, Sweden. 00:41.000 --> 00:46.000 So, the developer at a consultancy called The Beolite. 00:46.000 --> 00:50.000 So, I'm mostly in Python, like, today I'm, like, 100% Python, 00:50.000 --> 00:55.000 but I've also been working with, like, functional programming, closure, 00:55.000 --> 00:58.000 and a lot of Node.js, and I was many, for many years, 00:58.000 --> 01:02.000 in the Microsoft space, like, dot net, and C sharp, and stuff like that. 01:02.000 --> 01:07.000 But today's, like, all in Python. 01:07.000 --> 01:13.000 So, I would like to, like, begin by try to, sort of, 01:14.000 --> 01:17.000 like, the definitions of this terminology. 01:17.000 --> 01:21.000 So, starting about monorepers, like, Python monorepers. 01:21.000 --> 01:24.000 So, what's that, and how does that work? 01:24.000 --> 01:28.000 And this thing called pololith, how does that come in, 01:28.000 --> 01:33.000 and what problems does it solve? 01:33.000 --> 01:37.000 So, let's say that we have, let's say that we have our 01:38.000 --> 01:40.000 Python service or app. 01:40.000 --> 01:44.000 Maybe it's a fast API service with a lot of endpoints, 01:44.000 --> 01:49.000 and it's kind of solves every business problem in the place you work today. 01:49.000 --> 01:52.000 So, a monoreper wouldn't make any sense there, 01:52.000 --> 01:56.000 because you have just your one service. 01:56.000 --> 02:03.000 But, at least, from my experience, the last couple of assignments, 02:03.000 --> 02:06.000 the companies, sort of teams that I've joined, 02:06.000 --> 02:10.000 we have, like, build larger apps, or maybe platforms. 02:10.000 --> 02:14.000 At one place, we have developed an e-commerce platform. 02:14.000 --> 02:19.000 So, a common approach to these bigger things is that you use, 02:19.000 --> 02:21.000 like, a microservice approach. 02:21.000 --> 02:26.000 Like, you separate the different parts of that platform or app 02:26.000 --> 02:29.000 into separate deployable artifacts. 02:29.000 --> 02:32.000 So, maybe, let's say that you have an e-commerce application, 02:32.000 --> 02:33.000 or platform. 02:33.000 --> 02:36.000 Maybe you have one place where you deal with your products, 02:36.000 --> 02:39.000 and a different place where you deal with your, 02:39.000 --> 02:43.000 with your, with the prices of that project, products, 02:43.000 --> 02:47.000 or maybe stock and ordering and stuff. 02:47.000 --> 02:50.000 So, they are, like, different parts. 02:50.000 --> 02:54.000 So, the thing that I have noticed, at least, 02:54.000 --> 02:59.000 the place I've been, is that when you have these microservice set up, 02:59.000 --> 03:05.000 many different services, you often have them in different repositories. 03:05.000 --> 03:08.000 Different git repositories. 03:08.000 --> 03:12.000 So, you might have, like, you start small, 03:12.000 --> 03:14.000 and maybe you develop new things. 03:14.000 --> 03:15.000 So, it starts to grow. 03:15.000 --> 03:19.000 You have more and more services that you deploy and run. 03:19.000 --> 03:26.000 So, I think, a common approach for teams that has this set up, 03:26.000 --> 03:29.000 is that you usually agree on that. 03:29.000 --> 03:31.000 It's a good idea that your services, 03:31.000 --> 03:34.000 let's say that all of them are Python, 03:34.000 --> 03:38.000 run, sorry, are structured in, in this, 03:38.000 --> 03:40.000 kind of same kind of way. 03:40.000 --> 03:43.000 So, you use the same tooling, like, linkeding tools, 03:43.000 --> 03:46.000 type checkers, and even the folder structure. 03:46.000 --> 03:50.000 So, when developers are going to, 03:50.000 --> 03:53.000 solve problems in different replos, 03:53.000 --> 03:57.000 they will kind of know the structure and how to use the tooling. 03:57.000 --> 04:02.000 Maybe you use make or just or something like that. 04:02.000 --> 04:06.000 Oh, I didn't start this. 04:06.000 --> 04:12.000 Okay, so, but after a while, 04:12.000 --> 04:16.000 you know, after some time of the development, 04:16.000 --> 04:20.000 maybe all teams doesn't work on all services all the time. 04:20.000 --> 04:24.000 So, you might have started to diverge a bit. 04:24.000 --> 04:27.000 You develop your new services and your, 04:27.000 --> 04:31.000 you use maybe use new tools, maybe, 04:31.000 --> 04:34.000 new versions of the same tools or different, 04:34.000 --> 04:38.000 like, maybe you had Sonic as a web server in one service 04:38.000 --> 04:40.000 and you have fast API in this service. 04:40.000 --> 04:43.000 So, it's starting to diverge because, you know, things evolve 04:43.000 --> 04:48.000 and tools like are developed. 04:48.000 --> 04:53.000 And, also, maybe some, you get new ideas on how to structure 04:53.000 --> 04:55.000 structure or your code. 04:55.000 --> 04:58.000 You see, this third one has this source layout. 04:58.000 --> 05:03.000 So, things might start to look a little bit different. 05:03.000 --> 05:07.000 I think that's at least a risk or a probability. 05:07.000 --> 05:11.000 And, but our risk of having these things is that, 05:11.000 --> 05:15.000 let's say that this team works on this service 05:15.000 --> 05:19.000 and they need this problem to be solved. 05:19.000 --> 05:22.000 And they know that that problem was solved in this service. 05:22.000 --> 05:25.000 So, we need a little bit of code from here. 05:25.000 --> 05:29.000 So, the easiest approach is just a copy and paste it. 05:29.000 --> 05:33.000 And, and I think that's quite common that you do that, 05:33.000 --> 05:36.000 but the risk of that is that you have starting to have 05:36.000 --> 05:39.000 duplicate duplications in your code base, 05:39.000 --> 05:42.000 like you duplicate it code in your platform. 05:43.000 --> 05:47.000 And, the worst scenario is that if that code part of the code 05:47.000 --> 05:49.000 has a bug, then you need to go all of the, 05:49.000 --> 05:52.000 or if you need to change something, you need to go to many places 05:52.000 --> 05:54.000 and change that. 05:54.000 --> 05:58.000 But, common way of solving this, these kinds of problems 05:58.000 --> 06:03.000 is to extract the common code into libraries. 06:03.000 --> 06:08.000 So, you can do that. 06:09.000 --> 06:14.000 But, then you will have another repo to maintain. 06:14.000 --> 06:17.000 And, you know, libraries really good, 06:17.000 --> 06:21.000 but then you need to have an agreement on versioning, 06:21.000 --> 06:23.000 maybe you semantic versioning. 06:23.000 --> 06:26.000 And, and if you want to make sure that most of the services run 06:26.000 --> 06:31.000 on the latest version, you need to keep all the services up to date. 06:31.000 --> 06:35.000 So, there are a couple of trade-offs and like risks 06:35.000 --> 06:39.000 with this kind of set of, especially as the platform grows, 06:39.000 --> 06:44.000 and you have starting to have a lot of services and a lot of code. 06:44.000 --> 06:47.000 Also, you're going to see something about libraries. 06:47.000 --> 06:48.000 Yes. 06:48.000 --> 06:53.000 You know, some code is like almost too tiny, too small 06:53.000 --> 06:57.000 to start creating like an entire library of it. 06:57.000 --> 06:59.000 Maybe it's like almost like code snippet. 06:59.000 --> 07:04.000 You know, like maybe you have like this dictionary parsing thing 07:04.000 --> 07:08.000 or how to set up a logger that you want to do in the same way 07:08.000 --> 07:09.000 in all the places. 07:09.000 --> 07:12.000 So, it's maybe it's like not worth making a library 07:12.000 --> 07:14.000 and versioning and deploying things like that. 07:14.000 --> 07:18.000 So, it's just easy to copy and paste. 07:18.000 --> 07:21.000 So, one solution to that problem is to 07:21.000 --> 07:25.000 would be to just grab all the code and put them in the same 07:25.000 --> 07:28.000 git repo, same repo. 07:28.000 --> 07:32.000 So, and that would be my definition of a monor repo. 07:32.000 --> 07:39.000 So, you have all the code, but you deploy separate things from it independently. 07:39.000 --> 07:43.000 So, a monolith, it's like a related to it, 07:43.000 --> 07:48.000 but a monolith is just if you have your repo and you have one thing 07:48.000 --> 07:49.000 that you deploy. 07:49.000 --> 07:54.000 So, a monor repo is where you have several, all the code in one place, 07:54.000 --> 07:59.000 but you deploy several different things. 08:00.000 --> 08:04.000 But managing a monor repo can be really, really difficult. 08:04.000 --> 08:10.000 I know I've been to join in teams that has, like a monor repo set up 08:10.000 --> 08:14.000 and with, you know, custom scripts and simple links 08:14.000 --> 08:18.000 and all this kind of magic to make everything work. 08:18.000 --> 08:23.000 And when you like open your IDE, at one place, 08:23.000 --> 08:26.000 you couldn't even navigate the code because it was like 08:26.000 --> 08:29.000 the editor didn't really understand the references. 08:29.000 --> 08:33.000 So, there are problems with the monor repos. 08:33.000 --> 08:38.000 It's not like the perfect solution just because you have a monor repo. 08:38.000 --> 08:43.000 But this is where this pololith thing comes in. 08:43.000 --> 08:55.000 So, pololith is an architecture or, well, it's a way of structuring your monor repo, basically. 08:56.000 --> 08:58.000 And it's really, really simple. 08:58.000 --> 09:00.000 It's like almost like it's too simple. 09:00.000 --> 09:04.000 When I was introduced to this, I was like, you know, 09:04.000 --> 09:09.000 if it was this simple, why didn't anyone come up with this before, you know? 09:09.000 --> 09:16.000 So, but the basic idea, the main thing is that you structure your monor repo 09:16.000 --> 09:22.000 and you have three top folders, one called basis, 09:22.000 --> 09:27.000 and now the components in a third one called projects. 09:27.000 --> 09:31.000 And if we see, let's say that we have all these different services in different 09:31.000 --> 09:38.000 recalls, what's common between these is that they have some sort of an 09:38.000 --> 09:43.000 interpoint. If it's a fast API service, you have this like, you know, 09:43.000 --> 09:47.000 where you define your interpoints, when you're with a decorator and things like that, 09:47.000 --> 09:50.000 or if it's like a CLI, you probably have a main function. 09:50.000 --> 09:54.000 So, they probably have some sort of an interpoint. 09:54.000 --> 09:58.000 And those things you would put in the basis folder. 09:58.000 --> 10:01.000 So, ideally, you basically have that interpoint, 10:01.000 --> 10:03.000 but it doesn't do much logic. 10:03.000 --> 10:07.000 Logic, it calls the other code in your interpoints repository. 10:07.000 --> 10:10.000 Interpoints should be like thing. 10:10.000 --> 10:16.000 And the rest of the Python code, you put in the components folder. 10:16.000 --> 10:24.000 If you would just copy it, it wouldn't look like the ideal polylif way, 10:24.000 --> 10:32.000 but eventually you will end up in having a list of namespace packages 10:32.000 --> 10:35.000 that are ideal are very thin. 10:35.000 --> 10:39.000 So, let's say that you have this folders structure, 10:39.000 --> 10:43.000 but you identify the different logical parts of it, 10:43.000 --> 10:47.000 and extract them into smaller namespace packages. 10:47.000 --> 10:49.000 And that's what's called components. 10:49.000 --> 10:52.000 So, the ideal is that they are flat and small. 10:52.000 --> 10:55.000 And it can be like a tech component. 10:55.000 --> 11:01.000 It can be something that does dictionary parsing or something really simple, 11:01.000 --> 11:06.000 or it can be more feature like maybe like a Kafka consumer producer. 11:06.000 --> 11:08.000 So, it doesn't have to be the same size. 11:08.000 --> 11:12.000 It can be different sizes, but logically they are like separate. 11:12.000 --> 11:18.000 So, you probably would have a long list of different components there. 11:18.000 --> 11:23.000 And just by looking at that folder, you will actually get a quick overview 11:23.000 --> 11:26.000 over what's in this monoray. 11:26.000 --> 11:29.000 If you have a fairly good naming in your namespace packages, 11:29.000 --> 11:32.000 you will understand what's in there. 11:32.000 --> 11:35.000 And the third part is projects. 11:35.000 --> 11:39.000 And this is where you would put all the Pi project homophiles. 11:39.000 --> 11:42.000 So, you don't have any Pi fan code in there, 11:42.000 --> 11:47.000 but you have like your thing that you want to deploy, 11:47.000 --> 11:49.000 you have the infrastructure of it. 11:49.000 --> 11:51.000 Like basically the Pi project homophil, 11:51.000 --> 11:54.000 maybe Docker files and things like that. 11:54.000 --> 11:58.000 The configuration of the actual project. 11:58.000 --> 12:02.000 And the idea is that each project reference 12:02.000 --> 12:06.000 to the code that lives in the components and bases. 12:06.000 --> 12:10.000 If there are several projects using the same component, 12:10.000 --> 12:13.000 they will use the same version of it. 12:18.000 --> 12:22.000 And this thing is what the structure of this is what's called 12:22.000 --> 12:24.000 the Ponylith workspace. 12:24.000 --> 12:28.000 So, you have the bases, components, and projects. 12:28.000 --> 12:35.000 But what we also have at the top level is a Pi project homophile. 12:35.000 --> 12:39.000 And that will contain all the bases, all the components, 12:39.000 --> 12:42.000 all your code, and all the third party libraries, 12:42.000 --> 12:45.000 that you use across the monorepo. 12:45.000 --> 12:49.000 So, that means, and this one is meant for development, 12:49.000 --> 12:52.000 because we develop at the top level. 12:52.000 --> 12:56.000 The project's folder is basically where you deploy things. 12:56.000 --> 13:00.000 But when you're doing development, you are working at the top level. 13:00.000 --> 13:02.000 And that means that you have one virtual environment, 13:02.000 --> 13:07.000 and that virtual environment will have all the code in your monorepo. 13:07.000 --> 13:13.000 And that also means that you have one set of linkeding rules, 13:13.000 --> 13:18.000 one set of type checking rules, and all the good things 13:18.000 --> 13:21.000 that we usually have in our projects. 13:21.000 --> 13:25.000 You have one set of rules for the entire code base. 13:25.000 --> 13:31.000 So, the development experience is basically like a monolithically. 13:31.000 --> 13:36.000 So, you have this kind of monolithical developer experience from it. 13:36.000 --> 13:42.000 And the developer experience is so important that you even have a separate folder for it, 13:42.000 --> 13:49.000 because you might want depending on what kind of where you want to begin 13:49.000 --> 13:51.000 if you want to start a new project. 13:51.000 --> 13:57.000 Some people want to start very way defining an endpoint and work from there. 13:57.000 --> 14:01.000 Other might want to experiment and try things out. 14:01.000 --> 14:06.000 And if you want to do that, you have a place where you can put your, 14:06.000 --> 14:10.000 if you use like pie charm, you have you know scratch files. 14:10.000 --> 14:13.000 It's something like that, but you will version them. 14:13.000 --> 14:17.000 You have your file, your Python module in the development folder. 14:17.000 --> 14:20.000 So, you can keep it an experiment and when you're ready, 14:20.000 --> 14:24.000 you can extract code into your component, maybe, or a base. 14:24.000 --> 14:28.000 So, it's like a developer, like a playground. 14:28.000 --> 14:32.000 You can also have like scripts, things that don't fit in, 14:32.000 --> 14:36.000 like in a regular structure, maybe you have like one of scripts 14:36.000 --> 14:38.000 that you run like once a multiple. 14:38.000 --> 14:42.000 So, you can put them there too. 14:42.000 --> 14:46.000 So, I mentioned the polarity thing is an architecture, 14:46.000 --> 14:50.000 so looking at it from like a sort of a high level. 14:50.000 --> 14:53.000 So, we have something called bricks. 14:53.000 --> 14:58.000 And bricks is the common name for components and bases. 14:58.000 --> 15:02.000 And bricks, polarity really likes Lego. 15:02.000 --> 15:04.000 So, it's about, thank you. 15:04.000 --> 15:07.000 It's about Lego bricks. 15:07.000 --> 15:10.000 And that's why we have a folder called basis. 15:10.000 --> 15:15.000 Because if you, if you have not developed Lego, but built Lego, 15:15.000 --> 15:20.000 maybe you have used a Lego base plate where you put your bricks on top of it. 15:20.000 --> 15:25.000 So, the base is the thin layer, the entry points to your app. 15:25.000 --> 15:29.000 So, that's the kind of the metaphor from a polarity perspective. 15:29.000 --> 15:35.000 And the Lego bricks that you build things from is the components. 15:35.000 --> 15:40.000 Then we have something called libraries, which is basically in third-party libraries, 15:40.000 --> 15:43.000 dependencies that we use. 15:43.000 --> 15:49.000 So, fast API requests, pedantic, all that good stuff that we need in our project. 15:50.000 --> 15:57.000 So, the combination of a selection of libraries and a selection of bricks becomes our project. 15:57.000 --> 16:04.000 So, in Poland, we have one or several projects. 16:04.000 --> 16:16.000 And each project just picks their bricks and the libraries that it needs to be deployed. 16:16.000 --> 16:26.000 So, and for Python, we have, with this kind of setup, you probably won't want some tooling support. 16:26.000 --> 16:28.000 So, this is the thing that I have developed. 16:28.000 --> 16:33.000 It's called Python tools for the polarity architecture. 16:33.000 --> 16:36.000 And it's just been picked up in the Python community. 16:36.000 --> 16:39.000 And I'm really, really, really happy about it. 16:39.000 --> 16:45.000 And it's like, if you want to, if you visit the page, you will find a discussion forum where people have like, 16:45.000 --> 16:46.000 kind of active forums. 16:46.000 --> 16:50.000 So, I'm really, really happy that it's at that state now. 16:50.000 --> 16:59.000 So, the Python tools for the polarity architecture is, basically, the main idea is that it will visualize your monoraper. 16:59.000 --> 17:04.000 So, you can see what's in there, what are the smaller parts, what is the big picture. 17:04.000 --> 17:08.000 And there's also like helper commands. 17:08.000 --> 17:13.000 If you want to create a component, if you want to create a project, 17:13.000 --> 17:19.000 you will use that by templating, basically. 17:19.000 --> 17:24.000 So, one of the commands, the most straightforward one is the polar infocoman. 17:24.000 --> 17:27.000 So, it's type, polar, and then there's a command. 17:27.000 --> 17:32.000 And the infocoman will show you an overview of your monoraper. 17:32.000 --> 17:38.000 So, I around this command in my example repository, which is tiny. 17:38.000 --> 17:42.000 It's like simplistic, and it's almost like it's two simplicity. 17:42.000 --> 17:50.000 It's very little code, but in a real world monoraper, you will probably have a lot more code. 17:50.000 --> 17:55.000 So, what this command will show you is all the bricks, all the basis and components. 17:55.000 --> 17:57.000 That's why they have different color. 17:57.000 --> 18:02.000 It will also show all the projects that you have in your monoraper. 18:02.000 --> 18:06.000 And it will show you the connection between the two. 18:06.000 --> 18:10.000 So, you can see where one brick is used in which projects. 18:10.000 --> 18:15.000 So, you get this kind of overview of your repository. 18:15.000 --> 18:23.000 There's also a Libs command, where you can find out what third party libraries are used in bricks. 18:23.000 --> 18:27.000 So, you can see, okay, this brick uses PyDantic. 18:27.000 --> 18:35.000 And you can also see where the libraries are used in which projects. 18:36.000 --> 18:45.000 And then we have the Deps command, which is, I use it mostly for like refactoring purposes. 18:45.000 --> 18:50.000 Because it shows you the relation between the basis and components. 18:50.000 --> 18:59.000 So, if you remember, the components are like Lego bricks, but one component can be made out of other components. 18:59.000 --> 19:02.000 So, it doesn't have to be like a one, one, two, one. 19:02.000 --> 19:08.000 If you have a small tiny, like utility component, it might be used in several other components. 19:08.000 --> 19:13.000 So, this command will show you like a matrix of how they relate to each other. 19:13.000 --> 19:18.000 So, again, this example is like, so it will just output a tiny matrix of a very little code. 19:18.000 --> 19:22.000 But in a real world scenario, you would have a lot bigger. 19:22.000 --> 19:28.000 You can also zoom in to an individual brick to see, I think, something to a component, 19:28.000 --> 19:30.000 also a brick called the message. 19:30.000 --> 19:34.000 So, I can see where it's used, and I can see what it's using. 19:34.000 --> 19:41.000 So, you can follow the kind of employee usage as well as that command. 19:41.000 --> 19:48.000 And I think this command, Polydiff is probably, I think it's one of the most useful, 19:48.000 --> 19:51.000 especially from a deployment perspective. 19:51.000 --> 19:55.000 Let's say that you change something in one brick. 19:55.000 --> 19:59.000 In this example, I'll change the Kafka brick, the Kafka component. 19:59.000 --> 20:01.000 I'll change something. 20:01.000 --> 20:06.000 And if I just, if I'm going to merge that into the main branch, 20:06.000 --> 20:10.000 I don't want to deploy all the project all the time. 20:10.000 --> 20:12.000 I don't want to deploy everything all the time. 20:12.000 --> 20:17.000 But I want to deploy the projects that are dependent on this change, 20:17.000 --> 20:19.000 or affected by this change. 20:20.000 --> 20:22.000 So, this command will show you. 20:22.000 --> 20:25.000 So, the Kafka brick is used in these two projects, 20:25.000 --> 20:28.000 but it's not used in these other projects. 20:28.000 --> 20:31.000 So, this is useful information for your CI, 20:31.000 --> 20:36.000 so you can determine on how what to do when emerging code. 20:36.000 --> 20:46.000 There's also like CI, friendly, shorter, so you can programmatically figure things out. 20:46.000 --> 20:50.000 I think this was my last slide, actually. 20:50.000 --> 20:52.000 And thank you for listening. 21:00.000 --> 21:03.000 Any questions? Yeah, I think you were first. 21:04.000 --> 21:05.000 Thank you. 21:16.000 --> 21:17.000 I thank you for the wonderful talk. 21:17.000 --> 21:20.000 If you can only have one virtual environment when you're developing, 21:20.000 --> 21:24.000 how does that work with different projects, 21:24.000 --> 21:26.000 need different Python versions? 21:26.000 --> 21:28.000 Good question. 21:28.000 --> 21:34.000 So, actually the basic idea with this pollinating thing is that you 21:34.000 --> 21:38.000 ideally have the same version across your entire web, 21:38.000 --> 21:42.000 because everything you have there is shared code. 21:42.000 --> 21:46.000 So, that's the ideal situation, 21:46.000 --> 21:51.000 but if you need something different for a while, 21:51.000 --> 21:55.000 then you can create a new component that has that separate version 21:55.000 --> 21:57.000 in your development environment. 21:57.000 --> 22:00.000 You can switch on and off the different components, 22:00.000 --> 22:05.000 but ideally, you should have the same version across the entire monorepo. 22:05.000 --> 22:06.000 Thank you. 22:09.000 --> 22:10.000 Thank you. 22:10.000 --> 22:16.000 Could you make a brief comparison with other tools like poetry? 22:16.000 --> 22:17.000 Please. 22:17.000 --> 22:18.000 Yes, thank you. 22:18.000 --> 22:22.000 Actually, the tooling that I have developed 22:22.000 --> 22:25.000 is built on top of tools like poetry, 22:25.000 --> 22:30.000 because I didn't want to reinvent how to import, 22:30.000 --> 22:32.000 sorry, install dependency, 22:32.000 --> 22:35.000 because poetry and all of these other tools 22:35.000 --> 22:37.000 has really good support with that. 22:37.000 --> 22:40.000 So, I built it on top of tools like that. 22:40.000 --> 22:42.000 So, if you're a poetry user, 22:42.000 --> 22:44.000 there's a poetry plugin for polylith. 22:44.000 --> 22:48.000 So, if you use UV, you use a separate CLI. 22:48.000 --> 22:52.000 So, it supports, I think, almost every like patch, 22:52.000 --> 22:56.000 MPDM, a lot of these package management 22:56.000 --> 22:57.000 and the dependency tool. 22:57.000 --> 22:59.000 So, it's not a competitor to poetry, 22:59.000 --> 23:01.000 but it's like an add-on, basically. 23:03.000 --> 23:04.000 Hi. 23:04.000 --> 23:05.000 Thank you for your talk. 23:05.000 --> 23:06.000 I think we're interesting, 23:06.000 --> 23:08.000 a very interesting problem here, 23:08.000 --> 23:09.000 relevant to many of us. 23:09.000 --> 23:11.000 So, what I can see happening is, 23:11.000 --> 23:14.000 let's see if component doing AI training, 23:15.000 --> 23:18.000 role training, and component doing an API. 23:18.000 --> 23:21.000 I can see it happening that I have a brick 23:21.000 --> 23:24.000 for my AI model, and that's then used by another team 23:24.000 --> 23:26.000 another dev for the API, 23:26.000 --> 23:28.000 which is not what it's meant for. 23:28.000 --> 23:30.000 How do we avoid that? 23:30.000 --> 23:31.000 Okay. 23:31.000 --> 23:35.000 So, the other team use it 23:35.000 --> 23:38.000 because they think they want something in there. 23:38.000 --> 23:39.000 Yeah. 23:39.000 --> 23:40.000 Okay. 23:40.000 --> 23:44.000 I think maybe that's like a communication problem, 23:44.000 --> 23:48.000 but if it's possible, maybe if you could extract the parts 23:48.000 --> 23:52.000 that the team needs from that AI component 23:52.000 --> 23:54.000 to separate components. 23:54.000 --> 23:56.000 So, the AI component can use it, 23:56.000 --> 23:58.000 and the other team can also use it. 23:58.000 --> 24:02.000 So, my suggestion would be to try to split that part out 24:02.000 --> 24:07.000 to find the shared need for that everyone needs. 24:07.000 --> 24:08.000 Basically. 24:08.000 --> 24:09.000 Okay. 24:09.000 --> 24:10.000 That's communication really. 24:10.000 --> 24:11.000 Yeah. 24:11.000 --> 24:12.000 Okay. 24:12.000 --> 24:13.000 Thank you. 24:19.000 --> 24:20.000 Hi. 24:20.000 --> 24:23.000 My question is related to testing. 24:23.000 --> 24:25.000 How would you structure your test, 24:25.000 --> 24:27.000 and within CI? 24:27.000 --> 24:31.000 Is it possible to only run test for a specific project? 24:31.000 --> 24:33.000 If you have components sharing, 24:33.000 --> 24:35.000 not projects, and things like that. 24:35.000 --> 24:37.000 How do you optimize that, 24:37.000 --> 24:40.000 to not run your full test with every time something changes 24:40.000 --> 24:41.000 for one component? 24:41.000 --> 24:42.000 Yeah. 24:42.000 --> 24:43.000 Good question. 24:43.000 --> 24:47.000 So, Ponellith doesn't have its own test runner, 24:47.000 --> 24:50.000 so it relies on, if you have like, 24:50.000 --> 24:54.000 Pite, the Piteist, or any other tool, 24:54.000 --> 25:00.000 but what it can deliver is a list of the changed bricks. 25:00.000 --> 25:04.000 So, like, Piteist has this query, 25:04.000 --> 25:07.000 or a marker feature. 25:07.000 --> 25:08.000 So, you can use it. 25:08.000 --> 25:11.000 If you have marked up your tests, 25:11.000 --> 25:13.000 or named them in a special way, 25:13.000 --> 25:16.000 that's kind of related to the brick that is changed, 25:16.000 --> 25:20.000 then you get a nice query from the Ponellith, 25:20.000 --> 25:22.000 from Ponellith command. 25:22.000 --> 25:23.000 Right. 25:23.000 --> 25:24.000 Thank you. 25:26.000 --> 25:28.000 Thank you for all the presentation. 25:28.000 --> 25:32.000 I have more of a bit of a hypothetical question. 25:32.000 --> 25:36.000 Let's say I have a project where I predict 25:36.000 --> 25:38.000 soon I will have multiple components, 25:38.000 --> 25:41.000 but currently I have like multiple projects. 25:41.000 --> 25:44.000 Do you, does it to expect you to have one single 25:44.000 --> 25:45.000 or virtual environment, 25:45.000 --> 25:48.000 or do you make a virtual environment project? 25:48.000 --> 25:50.000 How does it handle it? 25:50.000 --> 25:53.000 So, the recommendation is to have one virtual environment 25:53.000 --> 25:55.000 at the top, so you have everything. 25:55.000 --> 25:58.000 But I know that some Ponellith teams today, 25:58.000 --> 26:01.000 because they want to develop isolation 26:01.000 --> 26:03.000 for that specific project. 26:03.000 --> 26:05.000 So, they can navigate down to the project 26:05.000 --> 26:08.000 and start a virtual environment there. 26:08.000 --> 26:10.000 But that's not what I would recommend, 26:10.000 --> 26:14.000 but you can do that if you have these needs 26:14.000 --> 26:16.000 and need to separate things. 26:16.000 --> 26:18.000 But the ideal situation is that you have 26:18.000 --> 26:20.000 a virtual environment at the top, 26:20.000 --> 26:24.000 and one virtual or whatever you want to have it, 26:24.000 --> 26:26.000 but it's just one virtual environment. 26:26.000 --> 26:28.000 So, you have access to everything. 26:28.000 --> 26:31.000 We just wouldn't it cause it like a bloated virtual environment 26:31.000 --> 26:34.000 where you might get lost in the dependencies 26:34.000 --> 26:36.000 that's what I'm afraid of. 26:36.000 --> 26:37.000 Just lots of questions. 26:37.000 --> 26:39.000 By having one virtual. 26:39.000 --> 26:41.000 Yeah, like I have a completely like separate, 26:41.000 --> 26:44.000 I'm a data engineer, so I have a completely separate data processing 26:44.000 --> 26:48.000 versus some like DVD, which is really different package. 26:48.000 --> 26:49.000 Okay. 26:49.000 --> 26:51.000 And there's a completely separate. 26:51.000 --> 26:54.000 Okay, I think is mean that the virtual environment 26:54.000 --> 26:58.000 will contain everything, but the team only needs this part. 26:58.000 --> 27:02.000 But I think that's a trade-off, but I would go for that anyway, 27:02.000 --> 27:05.000 because then if you find out, 27:05.000 --> 27:07.000 there's a connection between the two teams 27:07.000 --> 27:09.000 that, hey, both of us needs this part. 27:09.000 --> 27:11.000 Then you can start share code. 27:11.000 --> 27:14.000 Even though they are completely different business domains. 27:14.000 --> 27:16.000 So, that's what you will probably discover 27:16.000 --> 27:18.000 when you have this monorepo and this polyester 27:18.000 --> 27:21.000 that's probably more things in common 27:21.000 --> 27:23.000 that you might think in the beginning. 27:23.000 --> 27:26.000 And just by separating out the code in smaller parts. 27:26.000 --> 27:27.000 Yeah. 27:27.000 --> 27:28.000 Perfect. 27:28.000 --> 27:29.000 Thank you. 27:29.000 --> 27:31.000 Thank you. 27:31.000 --> 27:32.000 Thank you. 27:32.000 --> 27:42.000 So, thank you very much for all these questions. 27:42.000 --> 27:45.000 And thank you to David for this excellent talk. 27:45.000 --> 27:47.000 Thank you. 27:47.000 --> 27:48.000 Thank you. 27:51.000 --> 27:54.000 Thank you.