dmulholl
commented
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 execing a .py file, but ideas on all fronts are very welcome :)
The root directory of my project is littered with configuration files; requiring the Ivy configuration file to be called
config.pydoesn't make its purpose obvious. One option would be to call itivy.py; another would be to load the.ivyfile 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 filenamebecomes "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-Cflag.) Is this a change you'd be open to?