Closed gvwilson closed 2 years ago
Sorry Greg, hectic couple of weeks.
I've had issues before with the config.py
file. It used to be called site.py
, which is why its content is still available in template files under a site
variable. I had a bug report from a user who found that his Python installation was trying to load a standard library module called site
and was loading the site's site.py
file instead and crashing. Now I think that was due to a misconfigured Python installation that was adding the current working directory to the import path, but I think that might have been standard for some distributions at the time (maybe conda?). Anyway, I ended up renaming the file to avoid the problem.
(I did consider renaming it to ivy.py
but there are a lot of import ivy
statements in there that would have triggered the same issue.)
I'm inclined to add site.py
back as an alternative as I like the name. I think adding .ivy
as an alternative was a mistake though -- it was intended for sites that didn't require an actual configuration file but that's a niche use-case that just adds noise to the documentation. I'm going to soft deprecate it by removing it from the docs but leaving it as valid in the code.
The order of operations issue is a tricky one. Ivy needs to load extensions before it parses the command line arguments in case an extension has registered a custom command, and it needs to parse the config file before it loads extensions in case the user has specified a custom path for the extensions directory. I've experimented with different orders over the years and there's no ideal solution, it's always a trade-off.
I'm not wild about the idea of reading settings from a .cfg
file -- I like the simplicity and flexibility of just exec
ing a .py
file, but ideas on all fronts are very welcome :)
Hi Greg, I've added support for specifying a custom list of filenames for the site confguration file via an environment variable in v6.4.0
. You can find the documentation here: http://www.dmulholl.com/docs/ivy/main/options.html
The root directory of my project is littered with configuration files; requiring the Ivy configuration file to be called
config.py
doesn't make its purpose obvious. One option would be to call itivy.py
; another would be to load the.ivy
file as a Python source file; a third (my preferred option) would be to allow Ivy to read settings from an[ivy]
section ofsetup.cfg
.I started working on that, then realized the order of operations makes it complicated: command-line args are parsed after the config file is loaded, so
ivy --config filename
becomes "load default config, parse arguments based on that information, then load a new configuration". (The same thing makes it difficult to implement a "change directory before executing" flag similar to make's-C
flag.) Is this a change you'd be open to?