1. Einstein Toolkit Avatar Einstein Toolkit
  2. Einstein Toolkit
  3. tickets
  4. Issues

Support user directories for configuration files

Issue #164 new
Ian Hinder created an issue

It would be nice to have a separate simfactory directory for all user customisations rather than mixing them in with the code. This way, one can update simfactory (or delete/recheckout) without having to extract all changes.

Here is one possible solution:

Allow the user to specify a "sf-config" directory (maybe there is a better name) in the defs.local.ini. Any configuration files, for example mdb entries, scriptfiles etc, should be searched for under sf-config first before looking in the standard location. One could then set

sf-config = simfactory.user

and put local machine definitions and scriptfiles and modifications to the standard ones which are never going to be committed. One could keep the same directory structure under simfactory.user as is in simfactory, or it might be better to just search for files in that directory, since all the files should have different names, and an extra hierarchy is just annoying.

Keyword:

Comments (6)

  1. Frank Löffler
    • removed comment

    What about a /.simfactory/ directory for this (which would have to be synced as well, but that shouldn't be a problem, should it)?

  2. Ian Hinder reporter
    • removed comment

    This breaks the Cactus convention of having everything stored under the Cactus tree. Many people have more than one tree, and perhaps would like more than one set of simfactory options. We should support this, as well as perhaps supporting what you suggest. I was thinking that we should actually support a PATH-type variable for looking for simfactory configurations. Then it could be set to: "standard SVN simfactory:site-specific:user-specific". We could also put /.simfactory on the path, for maximum flexibility.

    Another advantage of separating out the customised or additional configuration files is that users can manage them in version control systems. This is problematic at the moment if you wanted to use, for example, SVN.

  3. Frank Löffler
    • removed comment

    I can see your point of storing everything under Cactus. However, I already don't store simfactory inside Cactus. I have just one simfactory checkout and use it from every Cactus tree. For different options I would probably create different option files within that one simfactory instance. I don't see simfactory so much connected to Cactus. It's more a tool like rsync or mpirun in my mind.

  4. Erik Schnetter
    • removed comment

    We can have both, a /.simfactory and a Cactus/.simfactory.

    If we split things out that way, then we should rename defs.local.ini to defs.ini.

  5. Ian Hinder reporter
    • removed comment

    I agree, except I'm not sure that having Cactus/.simfactory is a good idea. It will be a hidden directory which I don't think is necessary. Maybe we could call it Cactus/simfactory.conf?

    Then we would need to modify SimFactory to search for certain types of files first in simfactory.conf, then in /.simfactory, and then in the current location.

  6. Erik Schnetter
    • removed comment

    Simfactory already uses the directory name SIMFACTORY (upper case so that it appears first in most directory listings) in several cases to store internal information that regular users do not want to see most of the time.

  7. Log in to comment
Assignee
anonymous
Type
enhancement
Priority
minor
Status
new
Component
SimFactory
Milestone
–
Version
–
Votes
0
Watchers
0
Jira Software: the preferred issue tracker for Bitbucket. Join the team!