Late last year and into this year (2024) I needed to take time off to recover from surgery. As my mind started to clear but my body was still healing, I started poking around some code. At the time I was playing Pokémon Go (PG) and wanted to build my own mapping application. Well not actually from scratch but build it using a bunch of Python that others had assembled. I was not successful, and it the reason why got me thinking about libraries vs. binaries.
Library vs. Binary reuse is one of those problems that has been around as long as I can remember. The first time I ran into it was when coding in C (pre-C++) and considering an #inlcude file (.h), a library (.LIB), or a dynamic link library (.DLL). I don't plan on rehashing that thinking now because we all know the right answer and so we can just move on.
The Python code / repositories I was trying to assemble for this purpose suffered greatly from the conflicting version problem. Where code in the same namespace was dependent on different versions of the same library. This creates a Gordian Knot of mixed versions that is very difficult to work out. I am no Python expert, but my understanding from those that are is that this can be a common thing in the world of Python.
Not to give Python a bad name, I know it would happen in Java too. Yes, there are ways to work around this, but I was more focused on getting the solution running that having to unravel dependency tree conflicts.
It was a walk down memory lane that got me thinking that a lot of the old problems I had as a developer are still around. I know the tools have gotten better at helping us manage these and lessen the pain of the problem, but the problem still exists.
No comments:
Post a Comment