Environment dir ext #29
Conversation
The new system allows administrators to still control the storage of environment files, although now by supplying additional methods on a common function rather than merely controlling a special variable for the root. The new system also allows further kinds of files, such as generic runtime data and template overrides. Unfortunately since the locations need to be changed in order to implement useful default locations for the newly distributed systems, we also end up breaking existing setups alongside the backwards compatibility that we lose due to the removal of *environment-root*. [Compatibility Breaking] [Setup Breaking]
There was a problem hiding this comment.
This seems like a good solution to the problem. The breakage is regrettable, but long term unavoidable. Maybe for #30 you could have a way to warn the user that they need to make some changes?
(To conform to semantic versioning, this change would be part of Radiance 2.0, but I don't know if you care about that.)
| @@ -683,14 +683,6 @@ See DOCUMENTABLE")) | |||
|
|
|||
| ;; environment.lisp | |||
| (docs:define-docs | |||
| (variable *environment-root* | |||
There was a problem hiding this comment.
Perhaps you could keep *environment-root* as a symbol macro call to keep some existing code working? It would still cause setup breakage though.
There was a problem hiding this comment.
That sounds very gross. I'd rather just force reliant code to migrate, though I heavily doubt anything except for radiance's bootstrap/launcher scripts has touched this variable.
|
I was actually going to use the migration facility to automatically move over configuration files from the previous location to the new one, and inform users to change modules to put data files in the new location, in case they stored any in the config directory. |
This fixes #28 but causes both compatibility and setup breakage.
Please advise.