Publishing Python packages is a natural step into developer seniority

Learning Python programming is not a continuous process. It resembles heated water, which abruptly changes its state around 100 degrees. The road to mastering programming skills is similar. Software developer reads and writes code - this process is and must be continuous, like heating water. Then, with sufficient mental mapping, the external trigger pushes a developer into a new state of seniority.

This external trigger can be the legendary laziness, and in fact, usually it is. A typical way of being a Python export is when:

• you realize that you repeat a lot of calculations in your script, and you pack those repeating lines of code into a function (level 1, from parametric to functions)
• it’s easier to group functions and data structures within one object (level 2, classes)
• you divide code into modules based on the logic (level 3)

Beginners usually won’t understand those changes, so laziness is not enough. Every transformation requires months of work up to the tipping point when a developer sees how to save time and why it should be done. Defining a function, class, or building a module is not an indicator of seniority - I assure you that those concepts are parts of Python programming courses. What does make a senior developer? Understanding when and why use or not those language structures.

And here’s something not covered in classic software development courses: package publishing.

It is much more than pushing your code into PyPI or conda.

Publishing a package requires you to understand the following concepts:

• testing,
• CI/CD pipelines,
• writing and generating documentation,
• dependency management,
• and finally, building and pushing a package into PyPI and conda.

This is definitively outside the reach of beginners. Even for experienced developers, it could be too much to bother. But this is yet another level of hierarchy of the Python software. Parametric scripts -> functions -> classes -> modules -> package (modules + infrastructure). At this level, software developers understand the software lifecycle, and what indicator of seniority could be better?

The final question is when? When should you start thinking about publishing? I can give a few examples, but listen to your laziness and expertise for the definitive answer:

• you start copying & pasting a module between projects. This module can be rewritten as a stand-alone package
• your project is well-developed and works on production within a larger CI/CD pipeline
• you see that something is missing in the ecosystem,
• you don’t want to use some package, for example, when it installs too many dependencies. You publish the same functionality as a small package

Bonus for Open Sourcerers 🧙 : if you have published Open Science Software, I recommend sending it to the JOSS journal. If your tool is designed for data engineering or visualization, it could be sent to the pyOpenSci ecosystem.