Publishing Python Packages: Learn the latest standards and tools for Python packaging

Maker

Hey PH! Over the last several years I've focused on creating modular code shared across our organization's platform, maintaining a few dozen Python and JavaScript packages. I've also come to love the open source community—though I don't contribute nearly as often as I'd like—and thinking about ways to solve some the issues project maintainers face in their day-to-day work. I hope that Publishing Python Packages can make even a small impact in helping project maintainers be more productive through tooling and automation, so they can continue focusing on their projects and communities. This book covers some of the things I wish I knew earlier when creating Python packages at scale, and makes recommendations about tools I've found to be productive in managing a wide array of projects. Maintainership is a unique experience for everyone, but I hope this book provides a few new tips and tricks to keep in your playbook. The book is still in early access, which means you can read what I've written so far and give feedback about the content. You'll get updates as new chapters become available, and if you join the mailing list you'll get additional resources along with some background on the writing process. You can use the promotion code at checkout on manning.com to get 35% off!

Report

3yr ago

Nick Sands

Hey Dane! Congrats on the new book! I've never contributed to an open source project, but am definitely interested in doing so. Do you have advice for choosing the right project and also how might I make it easier on the maintainer of the project? In other words, how can I make the experience for the maintainer as easy and helpful as possible? Thanks!

Report

3yr ago

Dane Hillard

Maker

Thanks for the question @nick_sands! I think a lot of maintainers would appreciate this attitude, alone! Some folks come into an open source project because they experienced an issue using that project in their own application, and they submit a pull request to make a change they assume everyone wants, without thinking about downstream impact. This can be jarring for maintainers because no plan or discussion happened—it ends up being unsolicited advice, basically. Fixes aren't usually free to incorporate, so in the worst cases it actually costs the maintainers more time than the preferred approach. Coming into a project asking, "What's your process? What do you need the most help with? Is this issue something I can take on?" is the kind of thing you see producing constructive and fruitful contributions. It often ends up being different work than you might think—an open bug report may seem important, but maybe the documentation is really suffering and people are complaining to the maintainers a lot about that behind the scenes. Asking what they need gives an opportunity to raise these things and discuss priority. To choose a project, it can make sense to either look for projects in a language or framework you know, or a project you really appreciate that you notice has some kinks to work out. That way you'll come in with some familiarity, or gain familiarity quickly because it's something that interests you. If it's a project you use all the time, it can be motivating because you'll not only be able to make an impact for others, but also benefit directly from your own improvements yourself. A lot of people start by making documentation improvements or looking for GitHub issues with the "good first issue" label on GitHub, and after they develop some rapport and trust with the project maintainers they'll take on bigger things. Many maintainers were actually former first contributors to projects 😄 Hope this helps!

Report

3yr ago