1. Home
  2. Training Library
  3. Programming
  4. Programming Courses
  5. Introduction to Third-Party Package Management in Python

Considerations for Package Selections

Start course

This content is designed to introduce new developers to managing third-party packages using the Python package index and a tool called Pip. This course is part of a series of content designed to help you learn to program with the Python programming language. 

Learning Objectives

  • The Python Package Index
  • The tool used to manage packages called pip
  • The tool used to create isolated Python environments named venv
  • Considerations to be made before installing a third-party package

Intended Audience

This course was designed for new developers wanting to learn Python. 


  • That you’re familiar with the Python runtime
  • That you’re familiar with the Python language syntax
  • This course assumes that you’re not yet familiar with how to install and manage third-party Python software

The Python package index contains thousands of packages used to solve a wide range of problems. Some are quite popular - being used by thousands of developers everyday. Some remain unused. And there’s an entire spectrum in between.

Before installing third-party packages there’s a few considerations that we as developers need to make. We’ll be reviewing these different considerations in this lesson. Let’s begin by skimming over the list of considerations and then we’ll dive deeper into each. This list is in no particular order.

  • Licensing

    • E.g. Does the package’s license allow you to use the code as needed?

  • Documentation

    • E.g. Does the package contain useful documentation?

  • Effort Savings

    • E.g. Does the introduction of this package save enough effort to justify using it?

  • Quality

    • E.g. Does the package contain tests that validates the code?

    • …Is the code close enough to be considered idiomatic?

  • Security

    • E.g. Does the package take reasonable considerations to maintain security?

These are just a few of the topics that you might consider when determining which packages to install. This is not an exhaustive list. Rather, consider these a minimum starting point for the topics to consider when selecting which packages to install. 

Let’s run through them each. First up: licensing. Make sure that when selecting a package you review the license type. Some types allow you to use the code however you need. Other’s are restrictive. Before installing any third-party packages take the time to learn if the license’s restrictions are acceptable. 

You don’t want to learn that a license isn’t going to work out after a few days of development effort with the package. As you encounter different types of licenses you’ll start becoming familiar with the types that best work for you. 

Next up is: Documentation.

Historically projects with good documentation become more widely adopted. Good documentation can save hours of reading other people’s code. Good documentation helps to explain the purpose of the project and how to use it. 

If all other considerations are roughly equal, documentation might tip the balance. If there are two packages that perform the same purpose and the main difference is that one has better documentation then 9 times out of 10 that’s the one I’ll choose. 

Considering documentation when selecting a package can save a lot of time. 

Next up: Effort savings.

Installing and using packages from the index can save hundreds of hours for certain problem domains. For example there are packages used to run web servers. These packages include hundreds of hours of development effort by multiple developers. 

However, not all problems need to be solved with third-party packages. Knowing when to use a third-party package and when to develop the solution for yourself is an intuition that you’ll gain over time. 

I try to consider code maintainability when determining if I should use a third-party package or not.  Here’s how I determine when to use a third-party package and when to write the code myself. 

I start with the assumption that third-party dependencies introduce overhead. This overhead is in the form of learning and understanding the code from the package as well as keeping this new package up-to-date with the latest version.

In order for the overhead to be worthwhile the package needs to offset this overhead. If a package saves enough development effort then long term maintenance might be worth the trade.

For very small projects, sometimes the standard library is all that you need.

If ten extra lines of code can save you from the need to manage third-party package versions - then it may be worth forgoing the package. For all other projects,  consider how much value you gain by using a third-party package. Attempt to determine if the investment in learning and maintaining a third-party package is worth it for your use case. 

For example: if your goal is to create a complex web application then it probably makes more sense to use a third-party web server package. The weight of this overhead is going to be different for different projects and packages - as well as for different code uses. Sometimes using a third-party package will make sense, and other times it won’t. 

Okay, next up is: Quality.

If you’re going to rely on code maintained by others you want some mechanism for defining the quality of the code. 

Imagine that I present to you two vehicles. 

  • One is built with high quality components; and it’s tested to ensure it meets safety standards.
  • The other is built in a haphazard manner with spare parts and does not appear very safe.

Which option would you prefer for a long trip? Third-party packages are similar to these vehicles. Some are higher quality than others. 

In the context of this discussion of code-quality relates to the likelihood of the code successfully achieving its purpose with as few mistakes as possible. When viewing just a few lines of code it can be easy to determine if code is functioning correctly. Because we can follow the flow of the interpreter through the code. 

However, the more code that exists the more difficult it is to flow through all the possible code branches to ensure that everything is working. This is a problem for which automated testing can help. Automated tests can be run to ensure that code does what is expected. After changes are made to the code the tests can be run to verify that the changes haven’t broken anything.

When evaluating a package it’s worth investigating how the package is tested, if at all. Knowing what is being tested and how will help you to understand the odds of changes introducing problems. Good tests can help ensure previously fixed bugs aren’t reintroduced. They can also ensure that objects behave as expected. 

When I’m considering code quality, I also tend to favor idiomatic code. Recall that idiomatic Python code is code written according to the current community standards. The closer code to idiomatic the easier it will be for Python developers to work use. So, I give this some weight in this consideration. 

Our final consideration is: Security.

When considering third-party packages-security is the consideration that I give the most weight. 

Here’s how I consider security for third-party packages. I attempt to determine the probability that any given package will result in certain types of security incidents. As well as the potential severity of those incidents. There’s a lot that goes into that consideration. If you’re working for a larger company there are probably already some existing standards for reviewing third-party packages. For the rest of us, we need to make that consideration using our best judgment. 

This is one of the more difficult aspects to consider because it involves other technical disciplines. Here’s some basic considerations that can become a baseline for reviewing the security of the package:

  • Does the package take reasonable considerations to maintain security?

    • Packages such as those used for web template generation used to follow an opt-in security approach. Where developers had to enable certain features to gain essential security protections. 

    • Over time many of these transitioned towards security by default. 

    • Packages that prioritize good security practices should take precedence over packages that don’t.

  • Does the package have a large enough community of developers to resolve any security bugs?

    • Bugs are a natural and expected aspect of code. However, if the package maintainers are active then the time it takes before the bug is resolved is likely within a reasonable time frame.

  • Do I trust this code enough to run it on my own operating system?

    • When running third-party code you’re giving the creator a lot of trust. The question is: have they earned that trust?

    • Trust is difficult to quantify for many reasons. However, there is a tendency in the tech world to give this trust to certain companies, groups, and projects.

    • For example: we all run other people’s code regularly in the form of operating systems, web browsers, video games, apps, etc. 

    • Some projects become so popular that they become used by thousands of developers. And due to the size of the community around the project, more trust tends to be given to the code. 

    • There’s no one way to determine if a package is trustworthy. However, some methodology should be applied to each package before you consider installing it.

Alright, this was not a complete list of all the considerations for package selection. The universe is too large and complex for us to distill this into an exact list. However, these considerations are a starting place. Use this as a rough guide alongside your own research when determining which package to select for any given purpose. 

Okay, this seems like a natural stopping point. Here are your key takeaways for this lesson:

  • Before installing and using a third-party package there are some considerations to be made. We reviewed a few.

    • Licensing

      • Ensure that you can adhere to a package’s license.

    • Documentation

      • Try and favor projects with documentation if all other considerations are equal.

    • Effort Savings

      • Try and ensure that the overhead of learning and maintaining third-party packages is worth the effort.

    • Quality

      • Try and find ways to ensure that a package meets your required quality standards.

    • Security

      • Try and find ways to ensure a package is trustworthy.

Alright, that's all for this lesson. Thanks so much for watching. And I’ll see you in another lesson!

About the Author
Learning Paths

Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.

Covered Topics