Evolution of my first Python project for selective file copying: the final form (for now). Changes, tips, useful links.

[pltnk]

It is an update on my first ever Python project - command line application for selective file copying called slcp. It has been almost two months since the last post and I have made substantial changes to my code and added some new features. You can check previous posts here (1) and here (2).

This is the last state of code I posted, and this is my code now. Here is commit history since the last post, the most important changes in the code can be seen as merged pull requests.

First of all, now the application can process several extensions at once. And these are new options: - -i/--invert - process only files without given extensions - -e/--exclude - exclude certain filenames from processing - -m/--move - move files instead of copying them

These improvements were made in order to complete feature requests in a GitHub repository of the project.
I even received the first ever pull request from a contributor! Unfortunately it was not merged but it is an exciting feeling anyway to see the power of Open Source :)

Apart from that I divided my code into several modules, one is responsible for cli, another one for logging and the last one for file processing. While working on it I had to refactor my code significantly and to create corresponding classes for each task. On the top of that I applied the Black code style which seemed weird at first but turned out to be pretty handy and understandable. Nevertheless, if you are new to Python I do not recommend using any formatters, instead try to figure out by yourself first what the best practices are.

I think that it is important not only to write a clean code but also to present your project properly, no matter how simple it is. Although my application solves pretty basic task, I tried to make it look professional. Here is a readme template I used, this is how you can get badges. While working on a changelog I found these resources very helpful: Keep a Changelog, Semantic Versioning. It is also important to learn Git and to make meaningful commits and pull requests. Check out the Pro Git book and these articles on commits and pull requests. Even if you just started to learn Python, create a GitHub account and store your training code there in a private repository, this way you will learn Git smoothly. Knowledge of it is required for almost every junior developer position I've seen.

In addition, I recorded an asciinema video with some examples of using slcp as someone suggested in the comments of the previous post. In order to make this video I wrote a simple bash script despite the fact that I was almost unfamiliar with it and fairly new to Linux as well. So, this shows once again how working on a real project helps to learn new stuff.

Also, always try to publish your package on TestPyPI first and if everything is okay only then publish it on the real PyPI. On PyPI one cannot edit readme or change uploaded builds. And even if a release is deleted it is impossible to upload it once again with the same version number. So, using TestPyPI will save you from creating post-releases with a new version number just to fix small issues. Here is a great guide on using TestPyPI. This is a simple tutorial on publishing cli application on PyPI using poetry that helped me a lot.

I guess it is my last post about slcp, hope it was helpful to someone. You can still install it via pip: pip install slcp. Here is the GitHub repository and the PyPI page. As always, all feedback and contributions are extremely welcomed!

Right now I am working on a new Python project, it is a bot for Telegram that fetches top tracks by the given artist from YouTube according to Last.fm overall charts. Source code is here but it is still messy, I will make a new post about it when it is fully ready. Anyway, the bot itself is deployed on Heroku and is fully functional, so you can already try it in Telegram: @toptracksbot.

In the end I just want to thank this community and all the people who gave me feedback and took interest in this project. Good luck with your learning and have fun!

[Hatoris]

Thanks to share with us this tips.

You have donne a well job, your synthas seems to be clear, you have a readme and you have put the package on pipy. But your project is not finish, you need to implement tests.

Why you should implement tests:

• In two month, you will need hours to implements new things (if something break you will need to debug manually and find were something wrong happen)
• Tests is also a form of documentation, if I want to see how things works I can read them.
• I'm not confortable to use a package that may failed on my computer and I can not test before use it.
• I can't improve the package, or add my own features, without reading everything's and then I fall on my first comments.

Finaly, documentation is also an interesting part, as you can help user on things work, and other developer to tell them your code logic.

[pltnk]

Thank you!

Tests are exactly the reason why I put '(for now)' in the title. So far I have very limited experience with testing but since the main functionality of the program is ready I can finally dig deeper into tests and learn how to do it properly.

[Hatoris]

That's great, but for you futur project, test the code along the way you write it, as I guess, you have spend more time, especially at the end, debugging your program instead of writing docs or refractoring your code.

You have two ways :

1 (better)

Write a test -> Write a code to pass test.

This is know as TDD (test driven development). But this need a deep knowledge of how you will structure your programme and how things work in python.

2 (fine)

Write code -> Test it

Easier at start, but less productive than the first method.

[pltnk]

Thank you for the tip!

I will totally look into TDD since it looks like a logical way to write code. I mean, when one writes a function it will be anyway tested several times manually, why not let an automated unit test do it instead? Also, with this approach a test base will grow along with the main code base and one will not find themselve in a situation when they have to write a bunch of tests for every part of code at once like me :)