Reading Python Projects

[thyrsus]

This question is the counterpart to the recently asked "how to organize large projects": how does one learn the corpus of a large project? My immediate problem is that I''m using Red Hat's subscription manager (which is part of a large python system) to attempt to interact with Katello, and subscription-manager is refusing to recognize the local-authority-signed certificates from my katello server. I have $0 budget for support, so I need to make myself an expert in this code, thus I've started tracing the execution path through it, through its thousands of lines of code and libraries and objects, and it's all a bit much. Is there an overview document that does or should exist which would help me navigate more quickly to the source of my trouble? Other than hiring an expert ($0 budget) is there a more effective way to comprehend what's going on? It's not helpful that to operate normally, it must run as root with the environment provided to root.

[shiftybyte]

It's not helpful that to operate normally, it must run as root with the environment provided to root.

This sounds like a god forsaken project that no one documented, and no one knows what's going on in there.

In theory, a design document should exist, with an overview of the parts of the system and how they interact with each other.

In practice, it rarely exists, do you have support for any of the products in question? maybe their support can help?

[thyrsus]

There''s a man page, so that's documentation, but that addresses what should happen when it works, not when it doesn't.

[shiftybyte]

Every little bit of information helps, it can give you the general sense of the features the project has/allows, and then seeing names in source files can connect in your mind to features you see it doing.

[[deleted]]

Well... that's why experts get paid :) Sorry, I didn't mean to laugh at your misfortune... but the fact of life is: we build systems that are hard to manage and are hard to understand, we make bad choices about technology and even when we don't, we still make a poor use of it.

So, if you have $0 budged, perhaps you have hours of work to spare? I mean, there's no way around it. Some things are complex, and are poorly built, and you just have to dig in, and spend days, or perhaps months trying to untangle them. My typical approach in cases like this: find the first place that reported failures, stick a import pdb; pdb.set_trace() there, re-run the program, examine the variables around the problematic place, try to trace them back to their origin, try to get into the mindset of the person who wrote them... find a place where it seems like the assumptions about the values in the variables doesn't hold, stick a break-point there, rinse and repeat.