I'm writing an automated installation script for a bunch of software, in Python. The purpose is for the script to fetch compressed files from a directory and install/configure each utility or application on a case-by-case basis.
Since each of these requires special treatment (and when it isn't required it's the exception and I'd rather be ready just in case it does need special treatment in the future), I decided to have a separate
.py file for each of them, with the main script automatically detecting which one to use based on name matching, the rules of which are in a central
A lot of these specific scripts require more or less the same imports, in addition to some that are specific to that file. So I decided that it makes sense, just like we do in languages like C, to have a "header" script which imports the commonly used modules and just import that in all the minor and specific scripts.
However, upon reading several questions on SO (here, here, here and here are a few) it seems the consensus is that you should never do this and instead explicitly import modules on each file, as required. The reasons given are:
- It's explicit and in line with Python's design philosophy
- It makes it easier to find dependencies with just a text search
I've considered these but I can't decide if they apply in my case. I will have 50-100 different files, each requiring some common imports and some imports specific to that file. It seems in line with "don't repeat yourself" to put all the common imports in one file and import that file. It also seems less error-prone (what if I change to a different module with the same interface and just need to change the
import statement? If it's in one place, I know it's correct everywhere, otherwise I'd need to change it in every file).
Regardless of the details of this specific project, in general, is there ever a good case to be made for a common imports file in Python?