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.