Modify

Opened 8 years ago

Last modified 8 years ago

#164 new enhancement

Support user directories for configuration files

Reported by: Ian Hinder Owned by: mthomas
Priority: minor Milestone:
Component: SimFactory Version:
Keywords: Cc:

Description

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.

Attachments (0)

Change History (6)

comment:1 Changed 8 years ago by Frank Löffler

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

comment:2 Changed 8 years ago by Ian Hinder

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.

comment:3 Changed 8 years ago by Frank Löffler

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.

comment:4 Changed 8 years ago by Erik Schnetter

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.

comment:5 Changed 8 years ago by Ian Hinder

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.

comment:6 Changed 8 years ago by Erik Schnetter

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain mthomas.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from mthomas to the specified user.
Next status will be 'confirmed'.
The owner will be changed from mthomas to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.