Question

I recently came upon a new project with Python as the code-base. I have never done Python before – coming from the C/C++ world of compiled code. I am running into some issues understanding my current codebase.

When we write code, we have our libraries (components that are more general than other code), and our application code (code that applies the library), right? In the projects that I’ve worked on before, I would keep both my library code and application in contained folders in one project folder. In C/C++ land, there would be a makefile (or some make system) that hooks everything together so that the includes all work appropriately.

    Project/
           Library/
                   Utilities.cpp
           Application/
                   Main.cpp
           makefile

The project that I am coming onto right now has its own library in the site-packages folder, which itself is located in the IronPython/Python system folder. That library code is ours, and is still “hot” and being worked on. The application code is elsewhere on the system.

This seems like it’s bad design, but my peers insist that this is “just how Python works”. Python supports including/importing. Shouldn’t everything just be self-containedr? It seems odd to scatter code like that.

Thanks!

Answer 1

Python libraries are usually installed via distutils or setuptools. Those utilties install the libraries in python’s site-packages folder, which is where python knows to look for libs when an import x statement is encountered.

Developing code directly in the site-packages folder seems a little odd, although there’s technically nothing wrong with it. Normally, you’d have something like this:

./app1.py
./lib1/__init__.py
./lib1/lib1.py
./lib2/__init__.py
./lib2/lib2.py
...etc

And then when you were ready to package the libraries up, you can use one of the above mentioned utils to do so (which would then install the libs into site-packages).

So, to answer your question: there’s no hard and fast rule. I think most python developers would frown on developing directly in site-packages.

*Setuptools also has a command called develop that installs a link to your development library in site-packages. I’ve used that a few times with good results.