External config + db file?

SkyCrawl commented 8 years ago

Hey @passiomatic ,

could I ask for the following specific alteration?

If you're busy or something, I could have a go at this, despite I'm practically a python newbie...

Configuration file

As of now, configuration file is hardcoded to be ./etc/config. I would like it to be configurable too so that it can lie outside the coldsweat package. This would be very useful for easier git pull and if I really were to make a Docker image for coldsweat (not sure at the moment but I'm thinking of it), it would be a tremendous help too :).

I can see two ways to go about this.

Number 1: An optional argument to sweat.py setup, e.g. python sweat.py setup -c <path> -u .... The problem with this is repeated usage. The configuration file should (maybe?) only be loaded once, as is the current state of affairs.

Number 2:
A little change in the setup flow:

python sweat.py config <path>
python sweat.py setup ...
...

At the moment, the configuration file seems to be a global variable, read at the first import of the coldsweat directory. That would probably have to be changed to: "read at the config command, where the <path> is optional (default ./etc/config)".

SQL lite database file

Do I assume correctly that the default sqlite:///data/coldsweat.db URL can be changed to point outside the coldsweat package?

passiomatic commented 8 years ago

Quick answer while I think about the rest of your proposal:

Do I assume correctly that the default sqlite:///data/coldsweat.db URL can be changed to point outside the coldsweat package?

Yes. Also you can have the log file to live outside the package, just use an abs path.

passiomatic commented 8 years ago

If you're busy or something, I could have a go at this, despite I'm practically a python newbie...

Yes, I'm pretty busy these days, I encourage you to go ahead and do a fork.

At the moment, the configuration file seems to be a global variable, read at the first import of the coldsweat directory. That would probably have to be changed to: "read at the config command, where the is optional (default ./etc/config)".

You have to start somewhere, that is, how Coldsweat knows where to find config information after the "sweat config path" step? I guess you are planning to save the information somewhere so the subsequent "setup" phase con start from there.

Your first proposal probably make more sense IMO, this basically means that every sweat command needs a "-c path" argument, if not given the ./etc/config is the default location. However, keep in mind that the whole machinery needs to work in (Fast)CGI and WSGI environments where sweat command line utility is not used.

SkyCrawl commented 8 years ago

Hmm, that got me really thinking... Looks like I only just realized that each sweat command is independent, including the configuration. Sorry for the confusion :(. In that case yes, the second proposal doesn't make sense. On the other hand, calling python sweat.py -c <path> ... every time doesn't make too much sense either (I thought only a single call would be needed). If we were to implement my suggestion, we should probably revise the execution model a little.

Option 1 - daemon

No idea if that's even possible, how difficult it would be or what requirements it would impose on end-users. Compared to the other options, however, this seems way too much of an overkill.

Option 2 - environmental variable

The config could be loaded from an environmental variable, so effectively, the user could set it to whatever he wants and the code would only change a tiny bit (instead of a hardcoded string path, we would have a string path taken from an environmental variable).

The problem with this might be permissions, system restart and in the extreme case, multiple running coldsweat instances.

Option 3 - scripting (not entirely exclusive with option 2, and probably also a much better choice)

To demonstrate the idea:

To run coldsweat: python my-coldsweat-startup.py.
To globally define the input configuration: set_config_path("..."). Needed only once, at the start of the script.
We could create a default script with complete examples so the user could just copy several lines, provide the unknowns and execute the script like the above example.

Effectively, users wouldn't need the Wiki anymore but like this, they might be exposed a little to internal code changes. No python knowledge should be necessary though, as the examples will be ready-to-use?

With this option, the default behaviour of the sweat utility can stay the same, while the scripting functionality will resolve my problem and perhaps some more problems (of other people) in the future :). Python is a dynamic language after all.

passiomatic commented 8 years ago

Option 2 - environmental variable

This is the easiest path I guess. For now I'm not going to patch Coldsweat to support this directly, though, since your use case looks too specific. It is easy enough to edit coldsweat/__init__.py and do whatever you need. Something like this would work (not tested):

config_path = os.getenv("COLDSWEAT_CONFIG", os.path.join(installation_dir, 'etc/config'))
config = load_config(config_path)

SkyCrawl commented 8 years ago

This is the easiest path I guess.

Idd, seems like it :). For my use-case, I think the third option is the best and I will, eventually, realize it. Thank you for your consideration and time.

passiomatic commented 8 years ago

After this PR https://github.com/passiomatic/coldsweat/pull/96 I think it's time to fix your initial issue. We need a simple way to tell Coldsweat where to find its config file. Did you have the chance to test the env variable approach?

SkyCrawl commented 8 years ago

Unfortunately, I didn't :(. Since around the time I closed the issue, I've been overwhelmed with duties and other software problems. Nevertheless, let me offer some thoughts:

I think the solution will work fine in most cases. Leaving individual platforms out of the equation, I can only imagine problems when you're dealing with threads (or different instances of your environment) or simply forget about that in the first place. Either way, the user is at fault and personally, I see three options how to help him realize:

print which config is being used,
print a warning if the default config is used,
require a confirmation from the user should the default config be used.

The first option seems to be the least obtrusive way, despite not the safest :).

passiomatic commented 1 year ago

I'm closing this since next Coldsweat version will be based on Flask which has various ways to handle configurations: env. vars, dot files, Python files, etc. which can be used to suite any needs. See https://flask.palletsprojects.com/en/2.3.x/config/

passiomatic / coldsweat