Modern Python Projects Transcripts
Chapter: Let's build a package
Lecture: Remove unnecessary files
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
This cookie cutter template has created a lot of files here, so let's quickly go through them, and remove those that we don't necessarily need.
0:09
So let's open VSCode and let's go through them one by one. So, first we have the editor config.
0:18
This is actually useful because it will set up a configuration file, no matter what Editor you're using. So if you have VIM or emacs or VSCode,
0:27
they will all respect this configuration file. Then we have gitignore with a lot of Python specific files, which is good. Then we have Travis yml.
0:38
I'm not planning to use Travis, so I can remove this file. We have a file where we can list all the AUTHORS. I'm going to leave it for now.
0:53
Then we have a contributing guide that explains how different people can contribute to this project So if they want to report a bug report,
1:02
they can goto GitHub Repository. That doesn't actually even exist. But we can always create it later.
1:11
And here are all the steps that people should do when they want to submit a pull request. This is actually very useful file.
1:18
Let's leave it. History is a file where you specify all the changes that happened in each release. So again,
1:25
another useful file, license since we created the MIT license. This is the whole text of it. Here, We have to MakeFile. That looks a bit complicated,
1:36
but actually it contains the typical stuff. So when we run maketest, we're gonna run pytest. When we run,
1:45
make test-all. We gonna run tox that will test our package under different versions of Python, flake 8 set as our linter,
1:54
we can remove some test files, Some compiled Python files and stuff like that. So, it's actually pretty useful file.
2:03
If you're following this video, I suggest you take a look and see what useful
2:07
commands you can find here. Then we have the manifest file that will be useful when we'll be building the Python package.
2:16
Typical. README with some badges from Travis from pypi and stuff like that
2:23
requirements_dev, So, here we have the requirements that I will use as a developer Not necessary the final requirements of the end user of the package.
2:33
So, for example, I have pytest here, but If people want to use my uptimer, I don't expect them to install pytest.
2:40
Then we have a setup.cfg with some configuration and setup.py which is the main file of the Python package.
2:49
Although now there are more and more projects that they're using. pyproject.toml also setup.py might be replaced in the future
2:56
but for now, this is the file that will be using. So, those are the requirements for the end user of our package.
3:10
So, whenever people want to install uptimer from pypi, they will also have to install everything that you specify in this list.
3:18
And finally we have the tox.ini file where we specify all the tox settings So here we say that our project should support Python 3.5,6,7 and 8.
3:30
Apart from that, we have some folders here, so let's go from the uptimer. So, here we have the init file that tells Python that,
3:37
This is a package, the CLI file where we can specify the CLI commands and the actual uptimer that should contain the main code of our project.
3:49
Next we have test folder. So again, the init file and some examples of fixteures and tests and actually here we have the
4:03
example of how to test cli cli application. So that's actually pretty useful boilerplate code.
4:11
Next, we have the docs folder, so we don't have to generate this sphinx documentation from scratch. As you can see,
4:18
there is a lot of things going on here, so we would have to go and modify all those files. But I will leave that for the end.
4:26
We have a folder with the VSCode settings that was just created. And finally, we have the .github folder that contains the issue template.
4:36
So this is a template file written in markdown that will be used when someone wants to create a new issue in your github repository for this project.
4:45
So, again, this is a very useful file when you want to give people a skeleton of, how they should document the issue with your code.
4:53
Otherwise, people will just write whatever comes to their mind like it doesn't work, fix it or whatever. Here,
5:00
atleast we tell them to specify which version of the package they are using. What's there Python version was the operating system and stuff like that.
5:08
So, again, very useful stuff. So apart from removing this travis yml file, the rest of the files can stay.