How to handle root paths in a custom package?

Question

I am writing a custom python package, which produces some files in a certain directory. This directory I call root_path and should be set by the user. So basically, it should be a conf variable but not stored in a file. At importing the package, my code looks as follows:

import my_package
my_package.Conf.root_path = "/custom/root/path/"
my_package.function1(parameter1, parameter2)
my_package.function2(parameter3, ...)
...

In the package, Conf is a config class and root_path is a class variable of Conf. In this way, the root path acts as some sort of global var. However, I haven't really seen anything like this, so I am asking myself if this approach reasonable? Is there maybe some more appropriate way to do this?

• Laiv: Out of curiosity, why isn't root_path a function argument? On the other hand. Do you realise that you are asking why no one makes libs whose configuration is backed by global variables? I mean, it's a question asked and answered many times in this stack
• Corram: Hmm in your link is there a question such that this is a duplicate? I don't want to pass as function argument, because then the user of this package needs to provide root_path as a function argument to each and every function they call, which seems quite unnecessarily complicated.
• Laiv: Not exactly duplicated, but the subject is the same. It's obvious that you think global variables are harmless and you wonder why they are not common. I linked 1.4K questions for you to reach your own conclusions.
• Corram: Ok, I will go with config objects like Greg suggested in his answers to avoid global vars. Thanks for your feedback also.

Answer 1

There is a fundamental design flaw with using static variables as configuration. It introduces global variables to your application. Instead, think of configuration as part of the application state for your package. While Python let's you use procedural and functional programming paradigms, I believe this justifies an object-oriented approach instead.

You will need to analyze each of the free-floating functions in your package and do one of two things:

1. Organize these functions into classes.
   • Pass configuration information as constructor parameters.
2. Create a configuration object and pass it as a parameter to each function that requires it.

Both are valid approaches, and you will need to weigh the benefits and drawbacks of each one for both maintenance of your package as well as integration of your package with other applications.

• Corram: Thank you Greg for bringing up configuration object, I will go with this. Regarding free-floating functions, I actually don't have many. function1and function2in my sample code are actually nothing more than wrappers around classes (meaning they simply instantiate a class and call a method from that class), because I think this could be more convenient for the package user, but maybe I am mistaken here.