Skip Straight To The Fun Part Of Your Project With PyScaffold

WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 7/6/2024 5:46:35 PM
Duration: 3466.166
Channels: 1
1
00:00:13.985 --> 00:00:25.190
Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So check out our friends over at Linode.
2
00:00:25.865 --> 00:00:33.085
With their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,
3
00:00:33.560 --> 00:00:39.580
including simple pricing, node balancers, 40 gigabit networking, and dedicated CPU and GPU instances.
4
00:00:40.495 --> 00:00:47.875
And now you can launch a managed MySQL, Postgres, or Mongo database cluster in minutes to keep your critical data safe with automated backups and failover.
5
00:00:48.230 --> 00:00:49.290
Go to python podcast.com/linode
6
00:00:50.790 --> 00:01:02.425
today to get a $100 credit to try out their new database service, and don't forget to thank them for their continued support of this show. Your host, as usual, is Tobias Macy. And today, I'm interviewing Florian Wilhelm about PyScaffold,
7
00:01:02.805 --> 00:01:07.990
a Python project template generator with batteries included. So, Florian, can you start by introducing yourself?
8
00:01:08.450 --> 00:01:11.829
Yeah. Sure. Thanks for having me. So, yeah, my name is Florian.
9
00:01:12.130 --> 00:01:13.990
I'm head of data science
10
00:01:14.369 --> 00:01:17.494
at Innovex. We are an IT project house.
11
00:01:18.115 --> 00:01:20.295
I got a PhD in numerical mathematics,
12
00:01:21.155 --> 00:01:26.400
and then I started in the field of data science. And throughout the whole time,
13
00:01:26.860 --> 00:01:30.000
even also in my studies, I was using Python.
14
00:01:30.300 --> 00:01:34.015
And, yeah, it's cool to be here at this podcast.
15
00:01:34.715 --> 00:01:37.295
And do you remember how you first got started working with Python?
16
00:01:37.755 --> 00:01:44.350
Yeah. Actually, it was even during my school times when I remember correctly. So when, I was doing internship
17
00:01:44.729 --> 00:01:46.590
at SAP, which is, like,
18
00:01:46.970 --> 00:01:51.725
1 of the largest software companies in Germany. And there, I had to to learn Perl
19
00:01:52.345 --> 00:01:57.340
for scripting. It was whole Perl 5 point 4, I guess. And
20
00:01:57.719 --> 00:02:04.115
back then, I was quite excited about Perl, but 1 of the colleagues told me that I should definitely also look into Python.
21
00:02:05.054 --> 00:02:09.555
Yeah. So he convinced me to take a look into Python, and
22
00:02:09.855 --> 00:02:16.030
I pretty much locked directly loved it and preferred it to Perl because it was way more readable
23
00:02:16.650 --> 00:02:20.110
and easier. And this is what got me started.
24
00:02:20.705 --> 00:02:27.525
1 of my favorite jokes about Perl is that most programming languages are write once, read many, and Perl is write once, read never.
25
00:02:28.960 --> 00:02:32.020
Yeah. Yeah. Yeah. It's exactly what they say about Perl. Yeah.
26
00:02:32.480 --> 00:02:44.155
And so in terms of the Py Scaffold project, can you describe a bit about what it is and some of the motivation that you had for building it and some of the overall goals that you had when you started it?
27
00:02:44.579 --> 00:02:45.159
Yeah. Sure.
28
00:02:45.859 --> 00:02:46.359
So
29
00:02:46.819 --> 00:02:48.680
when I was doing my PhD,
30
00:02:48.980 --> 00:02:51.159
so it was in numerical mathematics.
31
00:02:52.085 --> 00:02:59.545
So we also started to use Python as a kind of clue code for all our numerics code in c plus plus and Fortran.
32
00:03:00.400 --> 00:03:07.985
And in this research group, I was the guy who was really excited about Python and told everyone about Python, and people started using it.
33
00:03:08.465 --> 00:03:09.205
But then
34
00:03:09.505 --> 00:03:13.205
everyone was more like scripting, and pipe wanted to kind of
35
00:03:13.505 --> 00:03:15.045
help everyone to
36
00:03:15.420 --> 00:03:19.599
write proper packages so that we could share our software components.
37
00:03:20.219 --> 00:03:24.245
And the first thing I did, I was writing a huge, Wiki
38
00:03:24.545 --> 00:03:31.660
page. I think it was in in red mine or what kind of Wiki there was at the time. So I was writing, like, a whole documentation
39
00:03:32.040 --> 00:03:40.535
about, yeah, have this setup dot py, and you should put this in there. And don't forget to add this, and this is how you should do it.
40
00:03:41.155 --> 00:03:41.655
And
41
00:03:41.955 --> 00:03:52.260
when I later joined the first company after my PhD, I was also kind of taking this Wiki with me, all the knowledge I have gathered. And also
42
00:03:52.800 --> 00:03:58.285
in the first company at Blue Yonder, we also started to use Python for c plus plus code.
43
00:03:58.745 --> 00:03:59.725
And then I realized
44
00:04:00.265 --> 00:04:08.180
after a while so, okay. No 1 is actually reading my documentation anymore because it has grown to, like, 20, 30 pages.
45
00:04:09.120 --> 00:04:11.300
And I thought, okay. Why not just
46
00:04:11.815 --> 00:04:13.675
create some project generator
47
00:04:13.975 --> 00:04:17.355
for helping people to apply all the best practices,
48
00:04:18.215 --> 00:04:22.550
everything from the docs really easily because, yeah, the actual
49
00:04:23.250 --> 00:04:35.015
barrier was for them to read the docs and having some kind of project generator that boot straps your code and you can easily start using it is is way easier to just use.
50
00:04:35.395 --> 00:04:36.675
And this is basically when,
51
00:04:37.475 --> 00:04:39.449
it was back in 2, 000 14.
52
00:04:40.069 --> 00:04:49.885
Blue Yonder at the time was the company I was working for where I had this idea. I pitched it with my boss. He gave me some time to work on this
53
00:04:50.505 --> 00:04:52.764
and also allowed it to be open sourced,
54
00:04:53.785 --> 00:04:59.280
which I'm really grateful for that they allowed it. And, yeah, this is how it all got started.
55
00:05:00.460 --> 00:05:04.319
And then after I mean, now it's, yeah, it's 8 years ago,
56
00:05:04.685 --> 00:05:07.425
it started to grow and constantly
57
00:05:07.805 --> 00:05:08.305
evolve.
58
00:05:09.085 --> 00:05:10.705
And, yeah, the rest is history.
59
00:05:11.700 --> 00:05:21.925
The context of the fact that you started it 8 years ago is interesting because if you were to go today and look for, I just need a template for XProject. There are
60
00:05:22.544 --> 00:05:28.565
all kinds of different options out there. There are different cookie cutter templates. Some of them are 1 off. There are some kind of generalized options.
61
00:05:29.380 --> 00:05:51.240
And I'm wondering, at the time that you started the project, what the kind of available landscape looked like for somebody who just wanted to say, I just want a template that gives me a Python package that has all of the basic setup that I need so that I don't have to read through, you know, reams of documentation to figure out which configuration parameters to put where and what the, you know, the package architecture needs to look like?
62
00:05:51.780 --> 00:05:59.835
Yeah. So back at the time, I think it was also about the time when cookie cutters started, actually. And they also have a a Python template.
63
00:06:00.695 --> 00:06:06.500
But at the time, I was not really convinced, so I had different ideas how to tackle
64
00:06:07.200 --> 00:06:07.940
this problem.
65
00:06:08.320 --> 00:06:08.820
And
66
00:06:09.200 --> 00:06:10.100
yep. So,
67
00:06:10.480 --> 00:06:10.980
basically,
68
00:06:11.595 --> 00:06:18.175
the main idea was so the cookie cutter, you can basically use for for everything. Right? So you can roll your own templates.
69
00:06:18.930 --> 00:06:40.780
It's really easy to configure your own templates, but you still have to have the kind of knowledge. Right? Or if you look on the web page now, you have, like, tons of different templates, and somehow you need to decide. So what is the right template for me and what are the pros and cons of each template? And still, you have to kind of read a little bit in the documentation
70
00:06:41.240 --> 00:06:43.735
what it is really for and how you should use it.
71
00:06:44.294 --> 00:06:45.754
And the idea with PyScaffold
72
00:06:46.055 --> 00:06:56.210
is more or less that you have something really opinionated. That's kind of a best practice approach that comes with everything that you need to get started
73
00:06:56.750 --> 00:06:59.169
developing your own package really easily.
74
00:06:59.895 --> 00:07:03.435
And then there are, like, extensions that kind of deviated
75
00:07:03.815 --> 00:07:05.275
change a little bit
76
00:07:05.575 --> 00:07:08.715
the kind of basis, but it's not a complete new template.
77
00:07:09.160 --> 00:07:15.660
It's a different approach. So there's this core template, and you can alter it a little bit,
78
00:07:15.960 --> 00:07:26.075
which is in contrast to cookie cutter where you can have, like, complete different templates that are completely independent of each other. And I like the pie scaffold approach more.
79
00:07:26.490 --> 00:07:31.390
So the mission the goal always was to have, like, this 1 go to tool for beginners
80
00:07:31.770 --> 00:07:32.510
of packaging
81
00:07:33.290 --> 00:07:38.945
that you can just you know, you install, Py scaffolds. You run put up my project,
82
00:07:39.805 --> 00:07:40.305
and
83
00:07:40.685 --> 00:07:46.380
you have already a really nice scaffold there that comes with everything you need.
84
00:07:46.760 --> 00:07:50.699
You can easily build your package. You can upload it to PyPy.
85
00:07:51.675 --> 00:07:55.935
You can run talks for your unit tests using Pytest.
86
00:07:56.475 --> 00:07:57.855
You can build your documentation
87
00:07:58.235 --> 00:08:07.050
using things. You have pre commit, for instance, configured to have, like, black and flake, 8, and so on.
88
00:08:07.590 --> 00:08:08.810
And everything,
89
00:08:09.285 --> 00:08:10.265
like, is included.
90
00:08:10.725 --> 00:08:13.385
And, also, you have this nice documentation
91
00:08:13.765 --> 00:08:20.210
that we built over the years. So the web page explaining what everything is what everything does,
92
00:08:20.590 --> 00:08:23.570
and then you can kind of start step by step,
93
00:08:24.190 --> 00:08:26.690
like, using all those best practices.
94
00:08:27.235 --> 00:08:29.815
And I think this helps people a lot because
95
00:08:30.755 --> 00:08:32.454
if they weren't using PyScaffold,
96
00:08:32.835 --> 00:08:34.935
they would have to make a lot of decisions.
97
00:08:35.490 --> 00:08:41.590
So of what they should use, what kind of build system. I mean, nowadays, there's, like, can also use poetry
98
00:08:41.970 --> 00:08:43.430
instead of setup tools.
99
00:08:44.055 --> 00:08:49.355
You can use PDM, then there's hatch. So there are many different tools and also for documentations,
100
00:08:49.815 --> 00:08:53.730
different tools, and how to configure those. I think you can easily
101
00:08:54.270 --> 00:08:56.530
spend more than 1 week,
102
00:08:56.910 --> 00:09:06.504
like, just configuring your package and your whole development setup. But in the end, what you wanna do is to develop where you're working on your project, your idea.
103
00:09:06.805 --> 00:09:09.530
And so Py scaffold helps you to get
104
00:09:09.990 --> 00:09:14.410
really fast to the point where you can start just hacking away on your idea,
105
00:09:15.004 --> 00:09:17.985
and everything else is already with same defaults
106
00:09:18.524 --> 00:09:21.345
covered in in PyScaffold. So this is
107
00:09:21.725 --> 00:09:22.704
our main goal.
108
00:09:23.149 --> 00:09:35.205
As you mentioned, there are a large and growing number of options for any, you know, particular use case or any aspect of the kind of environment setup or the way that you structure your projects.
109
00:09:35.905 --> 00:09:38.565
And before we get too much into the details of
110
00:09:38.945 --> 00:09:40.645
which choices you've made where,
111
00:09:40.970 --> 00:09:49.790
I'm interested in discussing kind of the categories or types of applications that you're focused on supporting with PIScalfold and some of the ways that
112
00:09:50.175 --> 00:09:56.755
those areas of focus developed both from your own usage and some of the evolution of the project over time?
113
00:09:57.350 --> 00:10:00.650
1 main focus, you can build a library with PyScaffold,
114
00:10:01.110 --> 00:10:08.285
also some real Python application where you have console scripts and so on. So this is all supported.
115
00:10:09.144 --> 00:10:15.530
Then for specific applications, maybe thinking about, like, more data science or data oriented application,
116
00:10:24.165 --> 00:10:25.385
We basically
117
00:10:25.765 --> 00:10:35.500
we developed those extensions whenever we needed them. Since I'm in the field of data science, I brought the DS project for the data science project extension,
118
00:10:36.360 --> 00:10:39.180
and everyone can just contribute
119
00:10:40.305 --> 00:10:43.845
extensions whenever they want. But, yeah, we are completely open
120
00:10:44.465 --> 00:10:49.690
in this regard to whoever wants to contribute a new extension for some really specific
121
00:10:50.069 --> 00:10:53.850
use case. For instance, I saw last time I checked that someone
122
00:10:54.389 --> 00:10:57.895
had, like, a extension for Visual Studio
123
00:10:58.695 --> 00:11:00.475
Code together with a container
124
00:11:01.175 --> 00:11:01.675
configuration
125
00:11:02.295 --> 00:11:02.795
because
126
00:11:03.255 --> 00:11:05.755
1 person seems to, yeah, develop
127
00:11:06.240 --> 00:11:08.980
with the help of Visual Studio Code and, some containerized
128
00:11:09.600 --> 00:11:10.100
setup.
129
00:11:10.560 --> 00:11:13.915
And, basically, everything's possible with the help of the extension
130
00:11:14.375 --> 00:11:16.555
system. And I think at that point,
131
00:11:16.935 --> 00:11:19.115
huge shout out to Anderson,
132
00:11:19.654 --> 00:11:20.154
Bravoielli
133
00:11:20.535 --> 00:11:20.855
because
134
00:11:21.940 --> 00:11:25.960
so he's right now the core maintainer of PyScaffold, and
135
00:11:26.500 --> 00:11:28.200
he introduced the extension
136
00:11:29.415 --> 00:11:34.715
system back then. So he changed a lot to make this possible to have really
137
00:11:35.255 --> 00:11:39.210
yeah. To have extensions easily available in KiteScaffold.
138
00:11:39.910 --> 00:11:45.530
I'm definitely interested in digging into the extension system a bit. But before we get there, as far as the
139
00:11:46.615 --> 00:11:51.915
kind of decision making aspect of saying for this type of project, so for a Django project,
140
00:11:52.535 --> 00:11:54.635
these are the, you know, different
141
00:11:55.030 --> 00:11:59.690
basic plugins that you want to use. This is how we're going to default the project structure.
142
00:12:00.070 --> 00:12:07.775
You know, we're going to use Poetry or PDM or you know, just curious if you can talk through what your process was for
143
00:12:08.235 --> 00:12:11.695
deciding on what constituted best practices, both
144
00:12:12.190 --> 00:12:17.250
across all of the templates that you use in PIScalfold and for kind of each specific
145
00:12:17.950 --> 00:12:19.970
use case for a given project.
146
00:12:20.595 --> 00:12:23.895
Yeah. So, of course, everything's kind of opinionated.
147
00:12:24.275 --> 00:12:26.535
So we had huge discussions
148
00:12:26.915 --> 00:12:31.230
with several people from the Python community, or sometimes it was also just,
149
00:12:31.610 --> 00:12:35.550
like, trying out different tools. And so PyScaffold
150
00:12:36.090 --> 00:12:36.590
uses
151
00:12:37.435 --> 00:12:42.415
right now has been using setup tools because it's like the big default
152
00:12:42.715 --> 00:12:43.935
way of building
153
00:12:44.395 --> 00:12:45.295
Python packages.
154
00:12:46.210 --> 00:12:49.670
And since, also, setup tools evolved a lot,
155
00:12:50.210 --> 00:12:50.950
it's still
156
00:12:51.570 --> 00:13:02.635
used also a lot and has all the features that are needed. So we looked at different tools, for instance, Poultry. But on the other hand, Poultry itself also comes with a kind of minimal
157
00:13:03.570 --> 00:13:07.510
project setup. So and it also directly includes
158
00:13:07.890 --> 00:13:14.514
managing your whole virtual environments, and we wanted to have those separated that you, for instance, can also use
159
00:13:14.894 --> 00:13:15.714
an Aconda,
160
00:13:16.415 --> 00:13:22.970
which is maybe a little bit more preferred in the field of data science for managing isolated environments.
161
00:13:23.829 --> 00:13:25.850
And yeah. So, basically,
162
00:13:27.029 --> 00:13:27.769
we evaluated
163
00:13:28.475 --> 00:13:34.875
different ways and looked, of course, at a lot of other open source tools, how they are doing, and this kind of
164
00:13:36.050 --> 00:13:41.670
yeah, then helped us to kind of extract what we think are the best practices
165
00:13:42.210 --> 00:13:42.710
from
166
00:13:43.305 --> 00:13:48.445
different project. And, of course, this evolves over time. For instance, when we started,
167
00:13:49.225 --> 00:13:50.045
like, in
168
00:13:50.829 --> 00:13:51.329
2014,
169
00:13:52.110 --> 00:14:03.075
it was completely normal that you would write a setup dot py. Right? Because at first, Python was like, yeah. We can configure everything with the power of Python itself.
170
00:14:03.535 --> 00:14:12.839
And then later on, the whole community realized, okay. But being declarative is actually much better. So we should give up some of the huge power of Python
171
00:14:13.545 --> 00:14:18.365
and go over to some configuration file. And at first, this was a setup dotcfg.
172
00:14:19.545 --> 00:14:20.685
And, yeah, we welcomed
173
00:14:22.120 --> 00:14:41.610
this and implemented this too in Hinescaffold and always yeah. We are always keeping up with what setup tools does so that our users always have the current and most modern way of setting up setup tools. And now, I think since a few months, it's also possible to completely
174
00:14:43.110 --> 00:14:46.410
to completely configure setup tools with the help of pyeproject.toml.
175
00:14:48.070 --> 00:14:52.875
This is also gonna be, like, the next step, what we're gonna do. Then for documentation,
176
00:14:53.655 --> 00:14:54.235
I think,
177
00:14:54.615 --> 00:14:57.040
yeah, it was, from the start, pretty
178
00:14:57.340 --> 00:14:58.640
clear that Sphinx
179
00:14:59.340 --> 00:15:01.520
is the 1 go to tool.
180
00:15:01.900 --> 00:15:05.120
Right now, we are also evaluating MK Docs,
181
00:15:05.745 --> 00:15:10.805
which it seems like the community is, like, growing more in on the MK Docs side.
182
00:15:11.345 --> 00:15:16.510
When we started, most of the docs were written in restructure text. But nowadays, markdown
183
00:15:16.890 --> 00:15:17.390
is,
184
00:15:18.090 --> 00:15:25.485
much more preferred. So we first started this as an extension that you could say, okay. I wanna rather write it in markdown.
185
00:15:26.265 --> 00:15:36.209
And now we are thinking about maybe just to completely switch over so that your default project directly is all in markdown. But these are just ideas
186
00:15:36.589 --> 00:15:39.915
because we kind of want a way to have it standardized.
187
00:15:40.295 --> 00:15:43.115
And unit tests, I think, in the beginning before
188
00:15:43.735 --> 00:15:46.954
Pytest became really big, there were also a lot of other
189
00:15:47.490 --> 00:15:50.870
unit testing tools that we first checked out.
190
00:15:51.570 --> 00:15:54.070
And, yeah, this is how we kind of look
191
00:15:54.574 --> 00:16:07.610
what happens in the community. We also get, for instance, Anderson. He's, like, reading all those peps before going to sleep, it seems. So he knows all the peps and what we should implement next and so on.
192
00:16:08.070 --> 00:16:12.010
And then there's also a guy from setup tools,
193
00:16:12.695 --> 00:16:13.195
SCM,
194
00:16:15.654 --> 00:16:19.274
So he developed this tool. Yeah. Setup tools as SCM,
195
00:16:19.654 --> 00:16:23.060
and this tool allows you to do semantic versioning
196
00:16:23.600 --> 00:16:26.420
and kind of bridges the gap between
197
00:16:27.120 --> 00:16:27.620
git
198
00:16:28.295 --> 00:16:28.795
and
199
00:16:29.415 --> 00:16:34.475
the version strings of your Python package. So you can just tag a certain commit,
200
00:16:35.255 --> 00:16:36.030
and this,
201
00:16:36.430 --> 00:16:41.170
version is then also used directly in the metadata of your project.
202
00:16:41.790 --> 00:16:46.035
Yeah, this allows you to avoid any kind of of conflict
203
00:16:46.415 --> 00:16:54.040
because you want this to be always consistent. Right? What you haven't get and what kind of packages you are building. And he's also
204
00:16:54.580 --> 00:16:57.000
giving a lot of really valuable
205
00:16:57.620 --> 00:16:58.120
suggestions
206
00:16:58.420 --> 00:16:59.160
to PyScaffold.
207
00:16:59.540 --> 00:17:00.680
For instance, he
208
00:17:01.115 --> 00:17:08.575
suggested that we change to the source layout so that you don't have the the actual Python package at the root of your project,
209
00:17:09.050 --> 00:17:10.910
but that you rather have a source
210
00:17:11.530 --> 00:17:12.030
directory
211
00:17:12.490 --> 00:17:21.985
and the package is a subdirectory of the source because this has a lot of advantages. And so this is basically how those best practices
212
00:17:22.845 --> 00:17:26.625
so we listen to different ideas. We discuss them,
213
00:17:27.179 --> 00:17:32.240
and then we look, okay, who else is doing this? And is this already kind of a mainstream?
214
00:17:32.940 --> 00:17:34.080
And then we
215
00:17:34.700 --> 00:17:36.000
include it into PyScaffold.
216
00:17:37.645 --> 00:17:46.465
The kind of determination of what is mainstream is also interesting because it also depends a bit on who you're looking to for kind of signals where
217
00:17:46.990 --> 00:17:53.090
some kind of areas of the community are focused on, you know, everything should be in poetry, and we use pyproject.toml
218
00:17:53.550 --> 00:18:01.795
for everything. Other people are looking to some of the newer PEPs where I think PDM is 1 of the package managers that uses the
219
00:18:02.175 --> 00:18:09.530
directory based dependency management so that you can have sort of like a NPM style where you just install your packages into
220
00:18:09.910 --> 00:18:13.610
the project directory. You don't have to worry about managing your virtual environment.
221
00:18:14.235 --> 00:18:17.135
And I'm interested in your
222
00:18:17.674 --> 00:18:20.815
general kind of philosophy and approach for how you
223
00:18:21.630 --> 00:18:23.170
determine what your
224
00:18:23.790 --> 00:18:27.410
opinions are about how you want things to be done and how you
225
00:18:28.030 --> 00:18:36.195
balance that against the tendency for a project as it goes on to just add more and more configuration flags so that
226
00:18:36.640 --> 00:18:42.020
by the end of it, you might as well just do all the work yourself from scratch rather than rely on the, you know, so called opinionated
227
00:18:42.320 --> 00:18:46.020
approach because the opinions become diluted because there are so many options.
228
00:18:46.435 --> 00:18:47.975
Yeah. If we were actually
229
00:18:49.155 --> 00:18:52.375
now to switch setup tools for something else,
230
00:18:52.755 --> 00:18:55.030
then we would maybe over some
231
00:18:55.430 --> 00:18:56.810
time have a kind of,
232
00:18:57.990 --> 00:19:01.610
yeah, an extra flag to go back to setup tools.
233
00:19:02.070 --> 00:19:14.039
But then we kind of would drop setup tools if this ever happens. So we are still in discussion, and setup tools for me is still a it's still a good way to build your Python packages.
234
00:19:14.419 --> 00:19:21.559
But the idea is not to just add more and more and more, as you said, but to kind of replace them
235
00:19:22.005 --> 00:19:38.180
after a while, like, 1 thing with the other because you don't need to build tools, actually. So you have to decide anyway for a single 1. And since we wanna be a tool that you can just run and run put up my project, and then
236
00:19:38.535 --> 00:19:48.130
someone makes decision for you and gives you the default 1 where we think it's a good choice for you. And, I mean, right now, all those different
237
00:19:48.590 --> 00:19:54.335
things, build systems and also environment managers like PDM, Hatch, Poetry.
238
00:19:54.875 --> 00:19:59.775
There are so many. And right now, it's really hard to say who's gonna win in the end.
239
00:20:00.315 --> 00:20:04.570
And this is where we just kind of take our time and wait.
240
00:20:05.030 --> 00:20:06.570
And, also, actually,
241
00:20:07.510 --> 00:20:08.970
right now, pie scaffold
242
00:20:09.655 --> 00:20:11.755
doesn't really come with
243
00:20:12.455 --> 00:20:18.795
a way of managing your virtual environment. So it's completely agnostic, which I think is good. So you can
244
00:20:19.170 --> 00:20:30.934
do whatever you want. You can even use pipenv if you wanna use this, or you can use anaconda, whatever you want because we we are concentrating on this single thing, which is
245
00:20:31.235 --> 00:20:32.455
giving you a nice
246
00:20:32.835 --> 00:20:37.975
Python project setup. So it's not about managing your environments.
247
00:20:38.840 --> 00:20:44.700
There, you can still choose whatever you want. Maybe poetry, of course, would be a little bit
248
00:20:45.080 --> 00:20:48.540
difficult because, I mean, we use setup tools. So
249
00:20:49.195 --> 00:20:51.855
you would have to replace then some
250
00:20:52.555 --> 00:20:56.015
yeah. But in the end, after we have done the switch to Pyprojecttoml,
251
00:20:57.280 --> 00:21:00.500
it should hopefully be only, like, 1 line
252
00:21:01.120 --> 00:21:02.740
in the beginning of Pyprojecttoml,
253
00:21:03.760 --> 00:21:05.860
where you define your adult system.
254
00:21:06.335 --> 00:21:09.635
And then you could even use poetry. So, actually,
255
00:21:10.015 --> 00:21:11.155
if you wanna develop
256
00:21:11.855 --> 00:21:13.635
a Python library or application,
257
00:21:14.289 --> 00:21:22.549
you should not care that much about the build system in the best case because this should be completely transparent for you. It should
258
00:21:23.025 --> 00:21:29.445
just know the command how to build the wheel and not decide, okay. Should I rather go for there there's also flits.
259
00:21:29.905 --> 00:21:32.485
There are so many different tools, and
260
00:21:33.650 --> 00:21:37.990
some implement those caps. Some implement there's also PyFlux
261
00:21:38.530 --> 00:21:43.715
or something that only comes with this new way of the underscore underscore
262
00:21:44.015 --> 00:21:46.835
pipe packages. So this way of not having
263
00:21:47.534 --> 00:21:48.034
isolated
264
00:21:48.575 --> 00:21:49.875
environments at all.
265
00:21:50.340 --> 00:21:56.440
And yeah. So this is still some beast we kind of say, okay. We are re agnostic.
266
00:21:57.434 --> 00:22:08.410
Who knows if we later gonna adopt something or not? So I would rather actually keep or stick to the UNIX philosophy, which is do 1 thing and do it really well.
267
00:22:08.870 --> 00:22:15.450
And a project setup has actually or should, in best case, have nothing to do with how you
268
00:22:15.904 --> 00:22:17.205
manage your virtual
269
00:22:17.505 --> 00:22:20.085
environment. Right? It should be kind of a to
270
00:22:20.865 --> 00:22:23.800
it. Absolutely. You should just build the wheel, not reinvent it.
271
00:22:24.760 --> 00:22:25.260
Yeah.
272
00:22:26.840 --> 00:22:27.340
Absolutely.
273
00:22:28.200 --> 00:22:38.054
And then in terms of the actual implementation of Spy Scaffold, I'm wondering if you can talk to some of the ways that the project is designed and some of the
274
00:22:38.410 --> 00:22:49.155
choices that you've had to make in terms of how it is managed and structured and the evolution that it has gone through as the overall ecosystem and the adoption of best practices has changed?
275
00:22:49.695 --> 00:22:50.675
Yes. So implementation
276
00:22:51.135 --> 00:22:51.635
perspective,
277
00:22:52.975 --> 00:23:03.450
we always try to keep things as simple as possible. Right? So we also have nice documentation about this for contributors who beginners who want to contribute to PyScaffold.
278
00:23:04.755 --> 00:23:05.255
And,
279
00:23:05.555 --> 00:23:06.935
yeah, basically, we have
280
00:23:07.315 --> 00:23:09.895
a module for the command line interface,
281
00:23:10.275 --> 00:23:13.175
then we have a module for our internal
282
00:23:13.715 --> 00:23:15.910
APIs, So how to create a project.
283
00:23:16.770 --> 00:23:19.110
And then the base principle is
284
00:23:19.490 --> 00:23:23.645
that structure of your project, which is the kind of nested dictionary
285
00:23:24.025 --> 00:23:25.085
with the files
286
00:23:25.465 --> 00:23:27.325
and the content of the files.
287
00:23:28.105 --> 00:23:28.605
And
288
00:23:28.905 --> 00:23:32.660
and this put into a pipeline called the action pipeline.
289
00:23:33.360 --> 00:23:39.140
And each step of this action pipeline, which can be create a file or check the consistency
290
00:23:39.440 --> 00:23:41.460
of flags or make sure
291
00:23:42.065 --> 00:23:44.245
that git is there or initialized.
292
00:23:44.625 --> 00:23:48.085
This is then applied on each step on this structure.
293
00:23:49.179 --> 00:23:53.679
And in the end, the end structure at the end of the pipeline is then
294
00:23:54.140 --> 00:23:58.804
kind of deployed on your hard drive. So this is the basic idea.
295
00:23:59.265 --> 00:24:01.125
And this also gives the flexibility.
296
00:24:01.505 --> 00:24:02.645
So if your
297
00:24:03.424 --> 00:24:03.924
extension
298
00:24:04.225 --> 00:24:06.085
introduces another flag,
299
00:24:06.809 --> 00:24:17.095
then you have access to that flag. And, basically, you define a new action in this pipeline. You can say it should be should be run after after another step in this pipeline,
300
00:24:17.795 --> 00:24:19.655
and this gives you the whole flexibility
301
00:24:20.675 --> 00:24:25.110
to change at that point the project structure however you want it.
302
00:24:25.670 --> 00:24:31.530
And this is basically the whole magic. So I think it's kind of really simple to understand what's going on.
303
00:24:32.309 --> 00:24:35.049
And, yeah, throughout the time, a lot
304
00:24:35.414 --> 00:24:37.195
changed. So when we started,
305
00:24:38.135 --> 00:24:40.075
we wanted to have this versioning
306
00:24:40.455 --> 00:24:42.715
feature in there. I think it was
307
00:24:43.240 --> 00:24:48.940
way before setup tools SCM was actually invented, so we were using version here for that.
308
00:24:49.720 --> 00:24:52.715
And, also, we wanted to have declarative
309
00:24:53.495 --> 00:24:58.475
configuration options. So there was a time when we used this Python build reasonablest.
310
00:24:59.015 --> 00:25:00.155
So it's from OpenStack,
311
00:25:00.840 --> 00:25:01.340
PBR.
312
00:25:02.200 --> 00:25:05.100
So we were using this, and we were vendorizing
313
00:25:05.640 --> 00:25:06.620
those packages.
314
00:25:07.080 --> 00:25:09.740
And, yeah, later on, we decided to rather
315
00:25:10.175 --> 00:25:11.875
use, like, real dependencies
316
00:25:12.255 --> 00:25:14.755
for this. So the reason for vendorizing it
317
00:25:15.135 --> 00:25:17.555
was that we were, at that time,
318
00:25:18.130 --> 00:25:19.510
a kind of development
319
00:25:20.929 --> 00:25:21.429
requirement.
320
00:25:21.809 --> 00:25:30.155
So we tried not to have that many dependencies. So we would just package everything into PyScaffold. So this changed in version
321
00:25:30.535 --> 00:25:31.674
version 4.
322
00:25:32.135 --> 00:25:34.235
So there were a lot of kind of architecture
323
00:25:35.095 --> 00:25:35.595
changes
324
00:25:36.120 --> 00:25:37.820
throughout the time. And
325
00:25:38.279 --> 00:25:40.140
I think the biggest 1 was
326
00:25:40.600 --> 00:25:43.419
the change to have an extension system
327
00:25:43.799 --> 00:25:46.115
that Anderson introduced. And he also
328
00:25:46.735 --> 00:25:47.955
helped to restructure
329
00:25:48.335 --> 00:25:49.155
and reorganize
330
00:25:49.455 --> 00:25:52.675
the source code a lot, which helped us to maintain
331
00:25:53.530 --> 00:26:09.705
this over so many years. Because, I mean, when I started it, 8 years is already kind of long for a Python project. Right? So much happened even to the Python language. There was also the switch from Python 2 to Python 3. And in the beginning, we wanted to support this. So we had 6
332
00:26:10.279 --> 00:26:11.899
also in the templates
333
00:26:12.200 --> 00:26:16.620
to help people develop a package that runs for Python 23
334
00:26:17.640 --> 00:26:18.700
at the same time.
335
00:26:19.405 --> 00:26:21.345
This then also got dropped
336
00:26:21.965 --> 00:26:28.065
after a while because nowadays, you basically don't care about Python 2 anymore. Right? So and this is how we
337
00:26:28.429 --> 00:26:28.929
evolve
338
00:26:29.549 --> 00:26:31.250
this. And for version 4,
339
00:26:31.789 --> 00:26:32.529
we also
340
00:26:33.070 --> 00:26:39.695
took the time to just see what happened over those 8 years. So I know if you know this this course,
341
00:26:40.315 --> 00:26:42.575
if it's pronounced like this. This is visualization
342
00:26:43.115 --> 00:26:44.015
tool for
343
00:26:44.460 --> 00:26:49.120
Git where you just put in your whole Git repo, and then it creates some nice visualization.
344
00:26:50.780 --> 00:26:52.080
We put the PyScaffold
345
00:26:52.700 --> 00:27:00.555
repo in this tool, and I think it's a 4 minute video where you can say see easily how much has changed
346
00:27:00.934 --> 00:27:01.434
over
347
00:27:01.880 --> 00:27:02.940
those 8 years.
348
00:27:03.560 --> 00:27:11.515
Really, a lot has changed over those 8 years. And sometimes it was a real challenge to keep up with all the changes and all the taps.
349
00:27:12.395 --> 00:27:14.175
And sometimes it's also hard
350
00:27:14.875 --> 00:27:18.735
to say no to people for kind of suggesting new features
351
00:27:19.460 --> 00:27:25.480
and saying, okay. Please, could we also have this and that? And then you think about, okay. It's not only
352
00:27:25.940 --> 00:27:33.965
implementing it. It's also maintaining it over many years and kind of removing something from a package. It's much easier it's much harder
353
00:27:34.450 --> 00:27:38.950
than actually adding something. So you also always have to keep this kind of balance
354
00:27:39.409 --> 00:27:43.669
between not adding too many features because you have to maintain everything.
355
00:27:44.274 --> 00:27:48.294
On the other hand, you also wanna be, like, welcoming to new
356
00:27:48.674 --> 00:27:49.174
contributors
357
00:27:49.794 --> 00:27:52.695
and to also allow them to, yeah,
358
00:27:53.550 --> 00:27:57.330
implement their ideas and help improve pie scaffolds. So
359
00:27:57.790 --> 00:28:00.930
Another aspect of the work that you're doing is that
360
00:28:01.315 --> 00:28:08.215
by being opinionated, you have to make your own determination about what constitutes best practices. And as you mentioned, that means
361
00:28:08.559 --> 00:28:15.140
staying up to date with the different conversations that are happening, the PEPs that are being adopted, the changes to the Python language and ecosystem.
362
00:28:16.000 --> 00:28:16.500
And
363
00:28:16.865 --> 00:28:21.205
in your work of doing that, I'm curious what you see as being the
364
00:28:21.585 --> 00:28:28.220
kind of noisiest or most volatile elements of what constitutes best practices and what are the pieces that are
365
00:28:28.600 --> 00:28:33.420
largely stable or widely agreed on. So I know that black, for instance, is
366
00:28:34.035 --> 00:28:40.375
generally accepted as a good choice. Obviously, there are people who have their own opinions who dissent, but it's
367
00:28:40.675 --> 00:28:41.575
fairly uncontroversial
368
00:28:42.115 --> 00:28:50.200
versus the question of kind of environment management that you were discussing earlier of Poetry versus pipenv versus PDM, etcetera.
369
00:28:50.595 --> 00:28:56.375
I'm wondering what you see as kind of the, you know, most stable versus most volatile elements of that ecosystem.
370
00:28:57.235 --> 00:28:59.575
So definitely something like Plaque
371
00:29:00.110 --> 00:29:01.650
and Flake 8.
372
00:29:02.190 --> 00:29:10.415
And, also, I would say, pre commit. So also having this end of line fixer and white space and everything that helps you kind of
373
00:29:10.875 --> 00:29:12.655
have a certain standardized
374
00:29:13.195 --> 00:29:21.280
style in your Python project. There is, I think, a lot of agreement that those tools make sense. Also, for unit tests,
375
00:29:21.580 --> 00:29:22.080
pytest
376
00:29:23.100 --> 00:29:27.920
is still the go to tool, I would say, and also talks
377
00:29:28.655 --> 00:29:30.035
for running tests.
378
00:29:30.575 --> 00:29:33.475
For a long time with regard to documentation,
379
00:29:34.095 --> 00:29:37.635
it used to be strings. But, yeah, as we mentioned before,
380
00:29:38.059 --> 00:29:42.799
people also use MK Docs. And what I like about MK Docs that it also
381
00:29:43.500 --> 00:29:44.799
has a declarative
382
00:29:45.100 --> 00:29:46.745
way of configuration.
383
00:29:47.045 --> 00:29:52.585
And Sphinx, on the other hand, has this const dot py where you also use Python for configuration.
384
00:29:53.445 --> 00:29:54.425
So then
385
00:29:54.860 --> 00:29:56.640
more and more people are adapting
386
00:29:57.020 --> 00:29:57.840
type hinting.
387
00:29:58.540 --> 00:29:59.280
So this
388
00:29:59.820 --> 00:30:00.480
is still,
389
00:30:01.500 --> 00:30:02.885
like, not 100%
390
00:30:04.625 --> 00:30:08.805
used, but there's a lot of agreement that people really like it. And,
391
00:30:09.160 --> 00:30:10.540
I mean, if you used
392
00:30:10.840 --> 00:30:11.340
Python
393
00:30:12.360 --> 00:30:18.695
docstrings to document your source code, you would anyway write if it's a list of int or a list
394
00:30:19.174 --> 00:30:21.674
of characters or whatever, a list of strings.
395
00:30:22.134 --> 00:30:24.154
And, yeah, having this now directly
396
00:30:24.615 --> 00:30:33.510
in the parameters of your function and the return value, I mean, it's it's much easier to read, and you have many, many benefits for
397
00:30:34.025 --> 00:30:44.890
instance, like static type checking. And there's also tools that even compile your Python codes, like the mypy compiler and so on. So there's a lot
398
00:30:45.270 --> 00:30:48.330
of things going on in this regard. So,
399
00:30:48.870 --> 00:30:51.130
yeah, mypy is definitely something
400
00:30:51.505 --> 00:30:54.065
I would say or it doesn't have to be,
401
00:30:54.465 --> 00:30:56.325
MyPy, I mean, also other tools.
402
00:30:56.945 --> 00:30:58.245
But type hinting,
403
00:30:58.870 --> 00:31:04.170
I would say, is yeah. Many people agree with it, and this is secure to stay.
404
00:31:05.270 --> 00:31:08.535
We also wanna support this more in high scaffold.
405
00:31:09.235 --> 00:31:12.295
Then when it comes to the build system,
406
00:31:12.835 --> 00:31:17.310
this is, like, really hard to say what's gonna happen there in the future.
407
00:31:18.250 --> 00:31:18.750
So
408
00:31:19.610 --> 00:31:21.790
I actually hope that setup tools
409
00:31:22.365 --> 00:31:30.065
is gonna be the winner because, I mean, it also does this 1 thing, and it does it also well. It has a kind of legacy code base.
410
00:31:30.730 --> 00:31:32.750
So this is maybe why people
411
00:31:33.530 --> 00:31:35.870
have their problems with it. And sometimes
412
00:31:37.050 --> 00:31:39.595
yeah. It has some really rough edges,
413
00:31:39.895 --> 00:31:45.275
so to say. So I had a lot of fun trying to understand what's, going on in setup tools,
414
00:31:45.655 --> 00:31:51.690
but I think it's improving a lot. So the Python package authority, the pipe PyPA
415
00:31:52.149 --> 00:31:53.690
I mean, they also have FLIT,
416
00:31:54.070 --> 00:32:01.575
which is like a light wide weight version of setup tool, so to say. But it also is missing a lot of features, like
417
00:32:02.275 --> 00:32:06.950
you can only have pure Python packages, so no compiled code.
418
00:32:07.330 --> 00:32:09.990
You don't have an extension system. For instance,
419
00:32:10.424 --> 00:32:15.325
what I explained before, this having semantic versioning directly from Git
420
00:32:15.865 --> 00:32:16.845
in your metadata
421
00:32:17.145 --> 00:32:18.365
of your Python package
422
00:32:18.730 --> 00:32:23.470
is not possible with Flit, which I think is a is a downside. So
423
00:32:24.090 --> 00:32:27.150
I'm not a huge fan of it, I must say, but
424
00:32:27.815 --> 00:32:32.875
there are many others. I haven't really evaluated so much PDM right now.
425
00:32:33.655 --> 00:32:35.200
And this new PEP
426
00:32:35.679 --> 00:32:38.580
with the local environments, with the Py packages.
427
00:32:39.519 --> 00:32:41.299
But then again, there's also Poetry
428
00:32:41.679 --> 00:32:50.534
and Hatch. Hatch is is definitely cool, I would say, because it already comes with a lot of features. But this is, I would say,
429
00:32:50.914 --> 00:32:51.654
the part
430
00:32:52.159 --> 00:32:54.100
where there's the most fluctuations,
431
00:32:54.559 --> 00:32:58.500
where it's not really sure what it's gonna happen. And I think,
432
00:32:58.880 --> 00:33:04.695
on 1 hand, it's kind of nice that people are inventing new stuff. But on the other hand,
433
00:33:05.155 --> 00:33:06.695
it's also a huge distraction
434
00:33:07.075 --> 00:33:07.575
because
435
00:33:08.035 --> 00:33:15.580
in the best way, you just you wanna have this 1 tool that you just use, and it does whatever you want. And
436
00:33:16.120 --> 00:33:21.175
you develop, like, other languages like Rust, for instance, come with cargo,
437
00:33:21.635 --> 00:33:25.255
where you have this 1 go tool how to handle everything.
438
00:33:26.195 --> 00:33:27.335
And it's actually
439
00:33:27.715 --> 00:33:30.360
a pity that Python had over,
440
00:33:30.740 --> 00:33:32.760
like, almost decades now
441
00:33:33.220 --> 00:33:36.040
so much pain with handling your dependency,
442
00:33:36.420 --> 00:33:37.160
with installing
443
00:33:37.495 --> 00:33:38.715
things, and so on.
444
00:33:39.495 --> 00:33:39.995
And,
445
00:33:40.375 --> 00:33:48.210
yeah, with respect to other things like, I would say, the the source layout of a Python package is also,
446
00:33:48.990 --> 00:33:53.570
yeah, many benefits of it so that you, for instance, cannot accidentally
447
00:33:53.950 --> 00:33:57.475
test something completely different because you import
448
00:33:58.175 --> 00:33:59.795
the package directly,
449
00:34:00.255 --> 00:34:01.795
not whatever you installed.
450
00:34:02.600 --> 00:34:03.100
So
451
00:34:03.400 --> 00:34:05.260
this, I think, is also kind of
452
00:34:05.640 --> 00:34:07.260
yeah. It makes sense. And
453
00:34:07.720 --> 00:34:11.315
most people agree that you should set up your project like this.
454
00:34:11.695 --> 00:34:13.795
Also, that you have should have a license
455
00:34:14.095 --> 00:34:15.315
file or,
456
00:34:15.855 --> 00:34:16.355
file
457
00:34:16.780 --> 00:34:17.600
called contributing
458
00:34:18.300 --> 00:34:19.200
and a readme.markdownor.rst.
459
00:34:22.540 --> 00:34:30.715
So the the over and and that your docs folders should be named docs, and you have a test folder. So certain things are already kind of,
460
00:34:31.095 --> 00:34:31.995
yeah, pretty
461
00:34:32.600 --> 00:34:35.580
defined. And I don't think that the overall,
462
00:34:36.360 --> 00:34:42.645
like, structure from a directory perspective is gonna change a lot. But, of course, you had some tools,
463
00:34:43.665 --> 00:34:47.765
yeah, some tools, especially the built systems. I think they
464
00:34:48.305 --> 00:34:51.410
they built surely changed a lot. And, yeah,
465
00:34:52.130 --> 00:34:54.230
let's see who's gonna win in the end.
466
00:34:54.770 --> 00:34:55.670
In terms of
467
00:34:56.450 --> 00:35:01.394
the extension system that you mentioned earlier, I'm wondering if you can talk to some of the ways that
468
00:35:02.015 --> 00:35:02.515
that
469
00:35:02.974 --> 00:35:03.474
enables
470
00:35:03.855 --> 00:35:04.674
people to
471
00:35:04.974 --> 00:35:05.875
use Pyscaffold
472
00:35:06.414 --> 00:35:10.630
as a utility and build their own templates and maybe some details
473
00:35:11.250 --> 00:35:15.830
on sort of how the templates are implemented as compared to maybe a cookie cutter template.
474
00:35:16.369 --> 00:35:17.030
The templates
475
00:35:17.490 --> 00:35:18.545
of PyScaffold
476
00:35:19.085 --> 00:35:19.585
are
477
00:35:20.445 --> 00:35:21.905
just Python packages
478
00:35:22.365 --> 00:35:25.185
themselves, so you can just pip install them.
479
00:35:26.079 --> 00:35:27.940
And, yeah, they're using the
480
00:35:28.800 --> 00:35:29.300
Python
481
00:35:29.760 --> 00:35:30.660
hooking system.
482
00:35:31.440 --> 00:35:33.460
So the entry points basically
483
00:35:34.079 --> 00:35:37.275
so that PyScaffold can discover those
484
00:35:38.295 --> 00:35:38.795
extensions.
485
00:35:39.975 --> 00:35:43.515
And they are discovered, and then you define
486
00:35:44.650 --> 00:35:46.750
your flags and your actions.
487
00:35:47.050 --> 00:35:47.790
And then
488
00:35:48.170 --> 00:35:50.910
you can also define where in the pipeline
489
00:35:51.665 --> 00:35:56.005
this extension this your your action is gonna be placed. So
490
00:35:56.305 --> 00:35:59.525
it's really not that hard to write an own
491
00:36:00.440 --> 00:36:03.020
extension. And we also wrote an extension
492
00:36:03.480 --> 00:36:05.500
to write PyScaffold extensions.
493
00:36:06.360 --> 00:36:08.255
So, you can just pip install
494
00:36:08.734 --> 00:36:09.714
install py scaffold
495
00:36:10.174 --> 00:36:12.115
dash custom dash extension,
496
00:36:12.894 --> 00:36:20.650
and then you have a special flag. And then you get a setup, a project setup that already includes all the necessary subfolders
497
00:36:21.030 --> 00:36:22.250
and has some stubs
498
00:36:22.710 --> 00:36:27.285
with pseudo code or not some pseudo code with, like, all the boilerplate code
499
00:36:27.825 --> 00:36:30.485
that you need to write your own
500
00:36:31.025 --> 00:36:31.525
PyScaffold
501
00:36:32.305 --> 00:36:32.805
extension.
502
00:36:33.670 --> 00:36:41.770
And, of course, also the the documentation, I think, at that point is really great. So it's it's not that hard to write your own extension.
503
00:36:42.485 --> 00:36:45.705
What cookie cutter does is clone some
504
00:36:46.405 --> 00:36:47.145
some GitHub
505
00:36:47.445 --> 00:36:47.945
repo,
506
00:36:48.325 --> 00:36:49.145
which uses
507
00:36:49.525 --> 00:36:52.410
Jinja or Jinja 2 to define
508
00:36:52.869 --> 00:36:55.369
the overall structure, and then there's some substitutions
509
00:36:55.830 --> 00:36:56.730
going on.
510
00:36:57.109 --> 00:37:01.685
So I think this is, like, really different to how we do it. So
511
00:37:02.065 --> 00:37:07.445
I must say that, of course, it's easier. So if you are already using Jinja a lot, then it's easier
512
00:37:08.010 --> 00:37:09.710
to write your own
513
00:37:10.650 --> 00:37:11.870
cookie cutter template.
514
00:37:12.650 --> 00:37:17.230
But on the other hand, I mean, the cook for a cookie cutter template,
515
00:37:17.965 --> 00:37:27.900
you would then need to decide first, okay, from which of the many templates are out there. I wanna kind of clone it and then do your changes.
516
00:37:28.360 --> 00:37:31.820
And in case of py scaffold, you always know that you have this
517
00:37:32.120 --> 00:37:35.340
core setup that is also gonna evolve over time.
518
00:37:36.015 --> 00:37:37.714
And then your extension
519
00:37:38.015 --> 00:37:38.515
just
520
00:37:39.214 --> 00:37:39.714
defines
521
00:37:40.095 --> 00:37:42.755
how you differ from this core
522
00:37:43.530 --> 00:37:47.230
definition of your project. And so this also means that maintaining
523
00:37:47.609 --> 00:37:48.510
your extension
524
00:37:48.890 --> 00:37:51.230
is way easier for PyScaffold.
525
00:37:52.410 --> 00:37:52.910
And
526
00:37:53.515 --> 00:37:54.575
it's a different
527
00:37:55.035 --> 00:38:00.255
thinking in this regard that you only define the changes and not like I copy everything
528
00:38:00.795 --> 00:38:02.495
and modify in place.
529
00:38:03.850 --> 00:38:09.150
For somebody who's getting started, you mentioned that you have this put up command to generate the scaffolds
530
00:38:09.530 --> 00:38:10.030
for
531
00:38:10.474 --> 00:38:22.089
somebody who maybe already has an existing project and wants to migrate to adopt some of the opinions that you are have encoded in py scaffold or for somebody who started a project in PyScaffold,
532
00:38:22.470 --> 00:38:27.369
but the underlying template has evolved, what are the options for being able to
533
00:38:27.875 --> 00:38:31.335
incorporate those changes into that existing project?
534
00:38:31.954 --> 00:38:33.015
We have a migration
535
00:38:33.474 --> 00:38:33.974
documentation
536
00:38:34.355 --> 00:38:35.175
about this.
537
00:38:35.510 --> 00:38:42.330
What you can basically do, it's, again, really simple. So just make sure that your current project
538
00:38:42.715 --> 00:38:45.935
already uses Git. I mean, this is, for instance, also something
539
00:38:46.475 --> 00:39:00.585
which is here to stay. So everyone uses Git. Right? There's no doubt about it anymore. So almost everyone agrees on this. This is also a requirement for ISCAPSOL. So let's assume that your current project, you're using git.
540
00:39:01.125 --> 00:39:03.305
Just make sure that that you have a clean
541
00:39:03.605 --> 00:39:04.825
repository. Everything's,
542
00:39:05.285 --> 00:39:06.025
checked in.
543
00:39:06.590 --> 00:39:11.570
And then you just go to the parent directory and type put up minus force
544
00:39:12.510 --> 00:39:14.610
and the name of your project.
545
00:39:15.310 --> 00:39:15.810
And
546
00:39:16.545 --> 00:39:18.805
and then PyScaffold is kind of overwriting,
547
00:39:19.744 --> 00:39:20.244
your
548
00:39:20.625 --> 00:39:23.444
current project setup with its own
549
00:39:23.744 --> 00:39:24.244
files.
550
00:39:24.840 --> 00:39:25.340
And
551
00:39:25.720 --> 00:39:28.780
then you can just git merge tool
552
00:39:29.240 --> 00:39:30.300
and git diff
553
00:39:30.600 --> 00:39:31.500
to kind of
554
00:39:31.925 --> 00:39:32.425
change
555
00:39:32.885 --> 00:39:37.865
whatever you need to change. So it depends if you already have a kind of similar
556
00:39:38.165 --> 00:39:40.825
project setup. Of course, there won't be
557
00:39:41.220 --> 00:39:42.280
that many changes.
558
00:39:43.140 --> 00:39:51.865
Yeah. If it's completely different, for instance, if you don't have the soft layout, there are some steps you can do before, but everything is written in the documentation.
559
00:39:52.805 --> 00:39:59.060
Of course, this process like this cannot really be automated because we never know how your project might look
560
00:39:59.860 --> 00:40:01.240
like. But I would say
561
00:40:01.780 --> 00:40:09.575
the process shouldn't cost you more than, let's say, 2 or 3 hours depending on how large your project is.
562
00:40:10.435 --> 00:40:11.815
And, yeah, it's kind of easy.
563
00:40:12.115 --> 00:40:15.095
And your experience of building Pyscoffold
564
00:40:15.395 --> 00:40:20.720
and using it and kind of evolving the project and now handing it off to a new maintainer,
565
00:40:21.340 --> 00:40:22.960
I'm wondering what your
566
00:40:23.340 --> 00:40:27.755
overall approach to community engagement has been as far as
567
00:40:28.135 --> 00:40:29.435
do you have any
568
00:40:29.735 --> 00:40:30.235
maybe
569
00:40:30.615 --> 00:40:44.885
voting process for deciding what are the right opinions to have or sort of who to listen to and what your approach has been for kind of bringing on your new maintainer and handing over the reins because that's 1 of the kind of least
570
00:40:45.984 --> 00:40:55.890
formalized or least understood approaches in open source as far as, like, how do you, as somebody who just starts a project because it's something a problem that you want to solve, then say, okay.
571
00:40:56.190 --> 00:40:59.089
This is how I am going to manage the
572
00:40:59.390 --> 00:41:00.369
kind of ownership
573
00:41:00.875 --> 00:41:04.175
and life cycle of this project once I have moved on to other things?
574
00:41:04.555 --> 00:41:06.954
That's a hard question. So I also
575
00:41:07.910 --> 00:41:16.650
yeah. I'm really open to all kinds of ideas and suggestions how to do this. Our current approach, and I think it worked quite well, is,
576
00:41:17.055 --> 00:41:20.675
first of all, be always be welcoming to new contributors
577
00:41:21.615 --> 00:41:26.250
and trust new people always. So you should not be too hesitant.
578
00:41:26.630 --> 00:41:27.609
And, yeah,
579
00:41:27.910 --> 00:41:29.289
listen to their ideas,
580
00:41:30.069 --> 00:41:33.895
kind of then also challenge their ideas, but in a nice
581
00:41:34.855 --> 00:41:37.435
way, and discuss first new ideas
582
00:41:37.815 --> 00:41:38.315
before
583
00:41:39.095 --> 00:41:41.355
you get some huge pull requests
584
00:41:41.660 --> 00:41:44.079
that change of, like, 80% of your code base.
585
00:41:44.540 --> 00:41:45.599
This can be formalized.
586
00:41:45.980 --> 00:41:47.839
So we have a lot of documentation
587
00:41:48.540 --> 00:41:50.720
about, as I said before, how our
588
00:41:51.365 --> 00:41:59.545
code looks like, also how to do your first pull requests. So, really, like, from the beginning, like, you click the clone button
589
00:42:00.020 --> 00:42:01.640
in GitHub and so on.
590
00:42:01.940 --> 00:42:02.760
So everything
591
00:42:03.300 --> 00:42:05.880
is included, and this helps new people
592
00:42:06.500 --> 00:42:09.964
making their first pull request. And we also had pull requests
593
00:42:10.505 --> 00:42:13.885
just fixing typos, which I really liked. And
594
00:42:14.265 --> 00:42:14.765
then
595
00:42:15.305 --> 00:42:21.470
I find it really important because it's, of course, writing open source code in most cases
596
00:42:21.770 --> 00:42:24.990
is nobody is paying for it. Right? So whenever
597
00:42:25.530 --> 00:42:26.030
someone
598
00:42:26.855 --> 00:42:27.835
wants to contribute,
599
00:42:28.295 --> 00:42:30.395
they are kind of giving you their
600
00:42:30.775 --> 00:42:36.075
spare time in most cases. Right? And I think this should always be appreciated. So if someone
601
00:42:36.700 --> 00:42:38.880
takes the time to fix our
602
00:42:39.180 --> 00:42:44.640
typos in pie scaffolds, so we are really grateful for this. And I think it's important to show this in a community
603
00:42:45.465 --> 00:42:48.205
that you write, hey. Thanks a lot.
604
00:42:48.505 --> 00:42:50.025
We also mentioned those in our
605
00:42:50.825 --> 00:42:53.485
as authors, as contributors to PyScaffold,
606
00:42:53.865 --> 00:42:58.460
and so on. So this is really important to have this, like, welcoming
607
00:42:59.080 --> 00:43:04.825
way for new contributors and always also explaining things when there are questions, of course.
608
00:43:05.205 --> 00:43:07.225
Also important is that
609
00:43:07.525 --> 00:43:13.090
when someone tries to make a first pull request, not to just think, okay. I can now
610
00:43:13.550 --> 00:43:15.890
implement whatever they ask for
611
00:43:16.510 --> 00:43:17.790
myself in maybe,
612
00:43:18.190 --> 00:43:24.454
2 hours because I know the code base, but rather to say, okay. You could implement it like this.
613
00:43:24.914 --> 00:43:31.830
And why don't you make a pull request for it so that people kind of get motivated? Okay. There's someone helping,
614
00:43:32.450 --> 00:43:34.150
and I write a small,
615
00:43:34.610 --> 00:43:43.975
maybe new unit test or whatever. And they fix a little problem, and then they have their first pull request. And this gets many people motivated then to
616
00:43:44.560 --> 00:43:47.300
go on and to maybe write a huge
617
00:43:47.760 --> 00:43:49.300
feature for PyScaffold
618
00:43:49.680 --> 00:43:50.580
and so on.
619
00:43:50.880 --> 00:43:56.325
And then there's always, like, trust. For instance, I trust Anderson, like, 100%.
620
00:43:56.865 --> 00:43:57.845
And I've
621
00:43:58.305 --> 00:44:04.180
known him now for many years. And, of course, if he has an opinion on something, this opinion
622
00:44:04.800 --> 00:44:07.380
is, like, really valuable. And this is also why
623
00:44:07.805 --> 00:44:09.985
I said, like, okay. I wanna also
624
00:44:10.445 --> 00:44:24.430
go on to other projects. So still, I want to contribute. But since you have been doing, like, the most work and the greatest feature in the last years, you have been implemented, so you should be the core maintainer
625
00:44:25.484 --> 00:44:26.305
of Pyescafold.
626
00:44:26.605 --> 00:44:27.424
And this
627
00:44:27.724 --> 00:44:28.865
is, like, the usual
628
00:44:29.484 --> 00:44:33.240
kind of, if you call it, ring of trust, or you have certain people,
629
00:44:33.700 --> 00:44:38.200
known them for many years, and they have done an awesome job. And, of course,
630
00:44:38.660 --> 00:44:40.119
you trust them more
631
00:44:40.500 --> 00:44:41.800
in contrast to someone
632
00:44:42.575 --> 00:44:43.075
coming
633
00:44:43.615 --> 00:44:45.875
in and saying, okay. I wanna change
634
00:44:46.255 --> 00:44:48.115
completely the goal of PyScaffold.
635
00:44:48.575 --> 00:44:52.579
Still, in this case, 1 has to be, like, really also, again, appreciate
636
00:44:52.960 --> 00:44:54.420
that they have cool ideas,
637
00:44:54.960 --> 00:44:56.500
but in a nice way,
638
00:44:56.880 --> 00:45:00.345
saying no. And this, like, learning to say no
639
00:45:00.805 --> 00:45:11.460
in an open source project for me was the hardest thing because you have motivated people, and they say, okay. Let's add this, and here's the pull request. And I've already put,
640
00:45:11.840 --> 00:45:20.985
like, maybe days of work into my pull request, so please accept it. And then saying, no. This changes the whole project into a direction
641
00:45:21.605 --> 00:45:26.609
that we kind of don't wanna go. It's the hardest part, but I think it's also
642
00:45:26.910 --> 00:45:27.410
something
643
00:45:28.109 --> 00:45:30.849
you have to do as an open source maintainer
644
00:45:31.744 --> 00:45:32.484
because, otherwise,
645
00:45:32.785 --> 00:45:36.164
you're kind of losing the goal of your project. So
646
00:45:36.625 --> 00:45:50.465
yeah. But I think there's a lot to learn still for us and for me how to do this. And as you said, I think maybe there's no no best way how to do or how to work with the open source community.
647
00:45:50.845 --> 00:45:53.345
Yeah. But, again, some best practices, I assume.
648
00:45:53.805 --> 00:46:02.900
In your work of building and using the project and engaging with the community, what are some of the most interesting or innovative or unexpected ways that you've seen Piscaffold used?
649
00:46:03.440 --> 00:46:07.140
I really like seeing that people are using the custom extensions,
650
00:46:08.005 --> 00:46:10.984
building their own, like, really specific extensions
651
00:46:12.005 --> 00:46:16.185
for their certain needs, like, something like on the b project
652
00:46:16.930 --> 00:46:18.710
and this Visual Studio Code.
653
00:46:19.410 --> 00:46:21.190
And someone also
654
00:46:21.490 --> 00:46:23.109
added an interactive
655
00:46:23.730 --> 00:46:24.869
shell for
656
00:46:25.375 --> 00:46:25.875
PyScaffold.
657
00:46:26.895 --> 00:46:27.714
So beforehand,
658
00:46:28.015 --> 00:46:32.275
everything was just that you define the configuration flags for PyScaffold.
659
00:46:32.815 --> 00:46:33.875
So 1 person,
660
00:46:34.740 --> 00:46:39.240
he built this interactive way, which I found really
661
00:46:39.780 --> 00:46:44.214
surprising because I actually never needed it. But we realized
662
00:46:45.474 --> 00:46:52.775
then due to him and also that other people were using this project that he built, that we should have this as a core feature.
663
00:46:53.540 --> 00:46:55.080
Yeah. But other than that,
664
00:46:55.540 --> 00:46:56.600
yeah, I think,
665
00:46:57.140 --> 00:46:58.280
yeah, most people
666
00:46:58.660 --> 00:47:00.040
are using PyScaffold
667
00:47:00.420 --> 00:47:01.560
as it is intended,
668
00:47:01.860 --> 00:47:04.175
and we are always happy to hear
669
00:47:04.875 --> 00:47:06.575
when people are using it.
670
00:47:07.115 --> 00:47:08.175
And yeah. So
671
00:47:08.795 --> 00:47:10.255
if you're using PyScaffold
672
00:47:10.955 --> 00:47:13.950
so to the listeners, yeah, let us know about it.
673
00:47:14.730 --> 00:47:16.750
Just use the GitHub discussions
674
00:47:17.290 --> 00:47:20.590
and tell us about it. We are really happy to hear
675
00:47:20.954 --> 00:47:23.295
what kind of projects you are using PyScaffold
676
00:47:23.674 --> 00:47:24.174
for,
677
00:47:24.714 --> 00:47:27.454
yeah, if it helps you or how it can be improved.
678
00:47:28.210 --> 00:47:30.470
In your work of building the project
679
00:47:31.090 --> 00:47:33.190
and growing it and now
680
00:47:33.490 --> 00:47:35.910
adding a new maintainer, what are some of the most interesting
681
00:47:37.015 --> 00:47:38.875
challenging lessons that you learned in the process?
682
00:47:39.655 --> 00:47:43.035
For me, this was my first open source project.
683
00:47:43.414 --> 00:47:47.580
All the community aspects that we discussed before, this was really challenging.
684
00:47:48.680 --> 00:47:49.180
And
685
00:47:49.960 --> 00:47:51.820
we have a few core contributors,
686
00:47:52.120 --> 00:47:56.545
but I would love to see a lot more people contributing to PyScafold
687
00:47:56.845 --> 00:47:59.664
and building this up. So this was really challenging.
688
00:48:00.605 --> 00:48:06.500
Also, keeping up with all the peps, of course, and that Python itself is
689
00:48:07.360 --> 00:48:08.420
really changing
690
00:48:08.960 --> 00:48:09.860
so rapidly
691
00:48:10.240 --> 00:48:11.620
for the whole language.
692
00:48:12.095 --> 00:48:23.880
I rather thought it's gonna be, like, maybe in, c plus plus or so that you have, like, a new standard every 4 or 5 years or whatever so that things are not changing so quickly.
693
00:48:24.340 --> 00:48:29.640
But Python has such a huge speed. Also, the whole ecosystem is is changing.
694
00:48:30.355 --> 00:48:31.655
And this is definitely
695
00:48:32.835 --> 00:48:36.135
yeah. It has been really surprising to me.
696
00:48:36.595 --> 00:48:39.415
It's still a huge challenge to keep up with this.
697
00:48:39.850 --> 00:48:48.955
For people who are looking for ways to be able to quickly scaffold or bootstrap a project or they're looking for an example of best practices
698
00:48:49.255 --> 00:48:50.315
for how to
699
00:48:50.775 --> 00:48:52.155
approach their application
700
00:48:52.615 --> 00:48:55.915
structure? What are the cases where PIScaffold is the wrong choice?
701
00:48:56.359 --> 00:48:58.619
I think it's the wrong choice
702
00:48:59.160 --> 00:49:00.220
if you
703
00:49:00.680 --> 00:49:08.505
wanna have a application that deeply integrates into your operation system, because then you would maybe rather go for some
704
00:49:09.285 --> 00:49:10.585
operation system specific
705
00:49:11.150 --> 00:49:14.610
packaging solution like a DPN package or Flatpak,
706
00:49:14.990 --> 00:49:17.170
Snap, whatever. But it's also
707
00:49:17.950 --> 00:49:18.690
the case
708
00:49:19.195 --> 00:49:19.695
for
709
00:49:20.075 --> 00:49:22.095
other type and packaging systems.
710
00:49:23.115 --> 00:49:23.615
And
711
00:49:24.395 --> 00:49:29.650
I think if you work, for instance, for a company or for some reason,
712
00:49:30.349 --> 00:49:32.849
the context you're working in demands
713
00:49:33.230 --> 00:49:33.890
a really
714
00:49:34.430 --> 00:49:35.650
specific setup.
715
00:49:36.335 --> 00:49:43.714
You're kind of deviating too much from what Hire Scaffold is giving you, then it really might make sense
716
00:49:44.095 --> 00:49:48.380
to use, for instance, cookie cutter instead and roll your whole
717
00:49:49.079 --> 00:49:49.579
template.
718
00:49:50.119 --> 00:49:53.099
And, yeah, this can be really a case where
719
00:49:53.535 --> 00:49:54.435
your own template
720
00:49:54.975 --> 00:49:57.315
that you then also, of course, have to maintain
721
00:49:57.935 --> 00:49:59.075
makes more sense.
722
00:49:59.455 --> 00:50:00.435
But if you
723
00:50:00.735 --> 00:50:05.280
kind of just wanna get going, then a pipe scaffold is the better choice.
724
00:50:05.900 --> 00:50:13.775
In terms of the near to medium term, what are some of the things that you and your co maintainer have planned for, you know, new capabilities
725
00:50:14.155 --> 00:50:19.135
or new areas of use or just some of the projects that you're excited to dig into?
726
00:50:19.770 --> 00:50:22.030
In the next version, we definitely
727
00:50:22.410 --> 00:50:22.910
wanna
728
00:50:23.370 --> 00:50:25.390
go to, yeah, wanna adapt
729
00:50:25.930 --> 00:50:26.430
Pyproject
730
00:50:26.745 --> 00:50:31.725
toml completely because this is now possible with the new setup tools version.
731
00:50:32.185 --> 00:50:33.565
So setup dotcfg
732
00:50:34.150 --> 00:50:39.289
is completely gonna disappear and all the metadata of your project. Everything's gonna be nicely
733
00:50:40.069 --> 00:50:40.890
in Pyproject.
734
00:50:41.349 --> 00:50:41.849
Toml.
735
00:50:42.230 --> 00:50:44.395
Also, we heard from the community
736
00:50:44.935 --> 00:50:45.755
that people
737
00:50:46.375 --> 00:50:51.435
rather have or rather want to have, like, 1 file with all the configuration
738
00:50:51.895 --> 00:50:57.660
in it instead of tons of small files, like file only with the flake 8 definitions
739
00:50:57.960 --> 00:50:59.420
and only with your coverage
740
00:51:00.405 --> 00:51:05.785
settings and so on. And most of those tools now integrate with pyproject.toml
741
00:51:07.525 --> 00:51:11.170
and also wanna integrate this. So this is definitely
742
00:51:11.710 --> 00:51:13.089
the near term goal
743
00:51:14.270 --> 00:51:15.250
for PyScaffold
744
00:51:15.790 --> 00:51:19.410
and also to have an update path for this next version.
745
00:51:20.015 --> 00:51:20.915
We are evaluating
746
00:51:21.215 --> 00:51:36.395
right now, for instance, MK docs, if this could be something, a switch to MK docs. So this is rather an idea I'm having right now, but, yeah, there still is gonna be a lot of discussion. Yeah. Anderson is the core maintainer. I'm gonna discuss it
747
00:51:36.875 --> 00:51:38.735
with him, so it's not yet decided.
748
00:51:39.275 --> 00:51:40.575
This is something then
749
00:51:40.955 --> 00:51:41.775
more integration
750
00:51:42.235 --> 00:51:45.455
of MyPy and to make it easier
751
00:51:46.150 --> 00:51:46.810
for people
752
00:51:47.430 --> 00:51:50.650
to then start with static type checking.
753
00:51:51.110 --> 00:51:52.490
So this would be something
754
00:51:52.790 --> 00:51:54.090
that's, like, midterm.
755
00:51:55.015 --> 00:51:55.515
And,
756
00:51:56.015 --> 00:51:56.515
also,
757
00:51:57.015 --> 00:51:58.555
we've really seen that
758
00:51:59.015 --> 00:52:04.850
people like markdown much more than structured text, and you can have it already in PyScaffold
759
00:52:05.150 --> 00:52:08.450
with the markdown plugin, which is, for instance, also
760
00:52:09.045 --> 00:52:11.224
by default install if you use
761
00:52:11.605 --> 00:52:13.305
the data science project plugin
762
00:52:13.605 --> 00:52:14.425
or extension.
763
00:52:14.964 --> 00:52:16.180
I think this should
764
00:52:16.660 --> 00:52:19.160
be, like, already in the default
765
00:52:19.460 --> 00:52:20.680
core setup
766
00:52:21.540 --> 00:52:23.000
so that you have markdown
767
00:52:23.460 --> 00:52:25.480
by default. So this is also
768
00:52:26.345 --> 00:52:27.565
rather near term.
769
00:52:28.025 --> 00:52:29.565
And then long term
770
00:52:29.945 --> 00:52:34.125
yeah. I really don't notice so much pace in Python's development.
771
00:52:34.665 --> 00:52:35.484
Let's see.
772
00:52:35.950 --> 00:52:38.450
Are there any other aspects of the PyScaffold
773
00:52:38.750 --> 00:52:41.250
project or the overall space of
774
00:52:41.710 --> 00:52:56.470
kind of managing the structure and best practices around the development of an application in Python that we didn't discuss yet that you'd like to cover before we close out the show? Yeah. Just like to mention also that if you want to contribute to PyScafold
775
00:52:56.770 --> 00:52:59.829
and if you have new ideas or if you wanna evaluate,
776
00:53:00.369 --> 00:53:00.869
especially
777
00:53:01.875 --> 00:53:02.375
tools
778
00:53:02.995 --> 00:53:05.495
like CATCH, PDM, and so on,
779
00:53:06.275 --> 00:53:13.079
and maybe have also a sister project or something that maybe works together with Py scaffold and yeah. Helps
780
00:53:13.779 --> 00:53:15.079
yeah. Or make suggestions
781
00:53:16.019 --> 00:53:18.920
that how you can or how to use,
782
00:53:19.299 --> 00:53:20.519
virtual environments
783
00:53:21.105 --> 00:53:24.005
and isolated environments or wanna help us with
784
00:53:24.385 --> 00:53:27.445
adding documentation about this. I mean, this would be
785
00:53:27.905 --> 00:53:28.965
really valuable.
786
00:53:29.730 --> 00:53:31.910
Other than that, I think this whole
787
00:53:32.530 --> 00:53:33.030
Titan
788
00:53:33.410 --> 00:53:33.910
packaging
789
00:53:34.610 --> 00:53:37.350
and structuring your project is really a
790
00:53:37.725 --> 00:53:41.265
huge rapid hole. So if you start looking into this, you will find
791
00:53:41.885 --> 00:53:43.105
a lot of EuroPython
792
00:53:43.885 --> 00:53:44.785
and PyCon
793
00:53:45.245 --> 00:53:45.745
talks
794
00:53:46.130 --> 00:53:46.869
going back
795
00:53:48.210 --> 00:53:49.750
to 2, 000 something
796
00:53:50.210 --> 00:53:51.589
where people discuss
797
00:53:52.049 --> 00:53:55.485
about the different ways of doing things. So it's
798
00:53:56.285 --> 00:54:03.345
actually, the less you care about this and the more you concentrate on your actual work or whatever you wanna do.
799
00:54:03.730 --> 00:54:05.670
So I think I have no more
800
00:54:06.050 --> 00:54:06.550
suggestion
801
00:54:06.850 --> 00:54:08.790
that you should look into something.
802
00:54:09.090 --> 00:54:11.910
So there's a few blog posts.
803
00:54:12.210 --> 00:54:12.710
I,
804
00:54:13.325 --> 00:54:15.345
yeah, could maybe add to the references
805
00:54:15.645 --> 00:54:16.785
of this podcast.
806
00:54:17.484 --> 00:54:19.025
I think 1 important thing
807
00:54:19.645 --> 00:54:21.080
that I see,
808
00:54:21.380 --> 00:54:25.880
especially in the field of data science, so people are using a lot of Jupyter and JupyterLab.
809
00:54:26.820 --> 00:54:28.200
And this brings
810
00:54:28.575 --> 00:54:29.315
own challenges
811
00:54:29.615 --> 00:54:32.595
of how to integrate this in a nice way
812
00:54:33.134 --> 00:54:36.914
into larger projects. So people start with 1 notebook,
813
00:54:37.500 --> 00:54:40.960
and then they realize, okay. The code is growing and growing.
814
00:54:41.580 --> 00:54:47.835
And at this point, how to migrate this into a proper Python project check with the help of PyScaffold.
815
00:54:48.295 --> 00:54:51.435
Yeah. It helps a lot. And we've also written
816
00:54:51.975 --> 00:54:53.995
1 blog post about this.
817
00:54:54.349 --> 00:54:55.170
This is definitely
818
00:54:55.630 --> 00:55:01.569
worth a read, I would say, for people in the field of data science because they're
819
00:55:02.109 --> 00:55:02.609
the,
820
00:55:03.105 --> 00:55:04.485
yeah, like, the software
821
00:55:05.025 --> 00:55:05.525
craftsmanship,
822
00:55:06.145 --> 00:55:08.325
so to say. Yeah. There's still a lot of potential.
823
00:55:08.625 --> 00:55:09.765
Let's say it this way.
824
00:55:11.070 --> 00:55:30.710
Well, for anybody who wants to get in touch with you and follow along with the work that you're doing and contribute to PyScaffold, I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the picks. This week, I'm going to choose the daredevil TV series I just started watching. Originally, it was aired on Netflix, and now it's on Disney plus.
825
00:55:31.589 --> 00:55:40.775
But definitely a very well put together show, a lot of, you know, interesting themes and interesting characters, so definitely recommend giving that a shot if you're into any of the superhero
826
00:55:41.075 --> 00:55:45.255
shows or genre. And with that, I'll pass it to you, Florian. Do you have any picks this week?
827
00:55:45.690 --> 00:55:48.270
Yes. So we started watching the peripherals,
828
00:55:49.610 --> 00:55:50.990
on Amazon Prime.
829
00:55:51.690 --> 00:55:55.230
It's, the creators of Westworld, which was already,
830
00:55:55.645 --> 00:56:06.850
like, a really cool TV show. I think there's season 4 also running right now. I haven't checked out yet. But, yeah, it's the second episode we have seen, and it's really interesting,
831
00:56:07.470 --> 00:56:08.530
really cool show,
832
00:56:08.990 --> 00:56:11.485
kind of sci fi, but also little bit
833
00:56:12.045 --> 00:56:14.145
mystery. You really have to think
834
00:56:14.605 --> 00:56:20.145
what's going on. So if you are, yeah, a fan of Westworld where you also don't know
835
00:56:20.890 --> 00:56:23.070
how things are, and it's a little bit mysterious.
836
00:56:23.450 --> 00:56:25.550
So it's a really cool show. So
837
00:56:25.930 --> 00:56:26.990
I'm gonna continue.
838
00:56:28.494 --> 00:56:38.130
Thank you again for taking the time today to join me and share the work that you've been doing on Piscaffold. It's definitely a very interesting project, and it's always great to have people contributing
839
00:56:38.750 --> 00:56:39.730
to helping to
840
00:56:40.349 --> 00:56:41.410
cement and
841
00:56:42.029 --> 00:57:01.345
share their thoughts on what constitutes best practices for how to structure your Python projects. I appreciate all the time and energy that you've been putting into helping save time and energy for everybody else who wants to just build something. So thank you again for your time, and I hope you enjoy the rest of your day. Yeah. Thank you. You too. And thanks for having me. It was really a pleasure. Thanks.
842
00:57:04.065 --> 00:57:17.170
Thank you for listening. Don't forget to check out our other shows, the Data Engineering podcast, which covers the latest on modern data management, and the Machine Learning Podcast, which helps you go from idea to production with machine learning. Visit the site at pythonpodcast.com
843
00:57:18.190 --> 00:57:26.005
to subscribe to the show, sign up for the mailing list, and read the show notes. And if you learned something or tried out a project from the show, then tell us about it. Email hostspythonpodcast.com
844
00:57:27.345 --> 00:57:33.520
with your story. And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.