Well, in practice when I fork a project and can't get – or don't want – my changes to be integrated in upstream, I rename the fork, in the README, I cite the original author but claim to be maintainer of that code source and link the source to my repository and in setup.py update the authors string to add my name after a comma:
name='renamedproject'
author='origauthor, me',
url='http://myfavoriterepository.com/me/renamedproject'
I have no sources to back me up, but that's the result of long discussions I had with other pythonista friends a while ago while drinking dark beers…
There are two problems come together here:
- Your package is a singleton although there exist many different configurations.
- Where to store the data and how to migrate - which database to use.
Singleton
I did a fun project with lots of modules which needed configuration themselves. The project was intended to run once per computer.
The alternative is to put everything into classes and instantiate them with a configuration. Tist would allow many different configurations to exist within one program. When you may have this need you should restructure your whole code.
Database
Maybe your project is for a company and shall be developed for a longer time and the configuration shall not be thrown away. Then you may need to keep in mind many previous configurations when changing the default values and updating the configuration. Proper databases have solved that problem.
My tradeoff solution
In my case
- The configuration can be thrown away if my model changes.
- The package runs not only once per process but also once per computer.
- Only one thread accesses the configuration.
There is a module called config.py with the following methods:
import config
config.load()
config.save()
You use it like this (Example1):
config.load()
config.my_value = 'test'
config.save()
There is also a file called constants.py which should better be called default_config.py. It has the functions
import constants
constants.default_configuration()
constants.config_file_name() # where to store the config data
And for (Example1) the constants.py should look like this:
def default_configuration():
return {'my_value' : 'default'} # to avoid attribute errors
The config module saves and loads the configuration using pickle. If no configuration is found for a variable the default configuration is used.
You will need a coding style that always fetches the configuration from the config.py. It shall not be stored in a local variable or attribute over a longer time since it can change.
My previous version is called runningConfiguration. It has no explicit load and save and also no default attributes.
Best Answer
Partition it like you would a normal library. There is no reason to include a monster god module if you only need it for one method. The other advantage of organizing pieces into pieces is that it will be easier to find something you need, but haven't used in a while. You don't have to remember that your prime generator comes just before the memoizer in the file. You can just jump straight into the prime module and see the other related methods that you could use but forgot were in your library.