Managing Python Dependencies
- Manually, which guarantees build stability but adds a lot of management overhead
- Requirements.txt or Pipfile, which eliminates self-management but requires version pinning to ensure stability
- Pre-built distributions, which guarantee build stability but may include far more packages than you need.
The ActiveState Platform addresses these common challenges and more. Watch the complete on-demand webinar here.
To get started, if you are working in Python and you have a very complex tree, it probably looks something like this. As projects get more and more complex, they’re built on more layers of packages, and it’s fairly easy, even when you’re at the top layer, for you to think you’re including two or three things but really, you end up including maybe 20 or 30 things. And what kind of insight do you have necessarily into the state of their security, but also in terms of compatibility amongst each other and all that kind of stuff? So we’re gonna look at some of the tools that are available to you for managing that in Python.
One of the the first and most low-tech ones is using vendor dependencies. The advantages to this are that you get guaranteed security, and that you you’ve personally vetted it and you’re the one controlling the code. You’ve got guaranteed compatibility and stability within your own source repo, and then also guaranteed availability, because it’s not being hosted externally on some cloud site. So there are some advantages. Obviously the disadvantages you’re seeing here are that you have a larger repo because you have to host all that code yourself, and you have to manually maintain it. So things could be out of date, you could get conflicts with other installs, and you might have to constantly reapply your own patches, that kind of thing. So it could be labor-intensive.
The standard way that’s currently done in Python is using Requirements.txt or a Pipfile. As we’ll see, the Pipfile is the new standard but the Requirements.txt is the existing standard. What you need to do is you have to install and build from a repo like PyPI or something like that. That’s where you get your code from, that’s where you download it, but you don’t have to maintain it and ship the code yourself. So you don’t have to bundle that source code with your application; you can just pull it down if you’re sharing the source. Obviously, you need to be aware that you need to pin versions to prevent bleeding-edge code from getting into your application, and then also, depending on how your development station is configured, you need to be considering using a virtualenv for isolation, so you’re not conflicting with the system install on a development laptop or something like that.
Now, the other method is pre-built distributions. This is the method ActivePython uses. This is a no-discipline approach, and what that is is that we’ve got the most popular packages already pre-built, tested, included in your distribution, and you get quarterly updates. This means that all of the work of making sure that the versions are compatible with each other, that there’s no security vulnerabilities, all that kind of stuff is done for you, so you know that I can just install this package and I’ve got pretty much everything I need for a working development environment. So as a standard install across a large organization, this can work quite well. Some of the downsides are that it’s not necessarily updated frequently, it might not be perfectly customized to your needs, or it might have more things than you need and be a bit big. And it may or may not fit your use case. It’s tailored to the most common use cases, but if you have a very specific one, you might find that that there’s something missing.
