[ET Trac] [Einstein Toolkit] #349: pyc files when syncing

[Einstein Toolkit]

#349: pyc files when syncing
----------------------------+-----------------------------------------------
  Reporter:  barry.wardell  |       Owner:  mthomas
      Type:  defect         |      Status:  new    
  Priority:  major          |   Milestone:         
 Component:  SimFactory     |     Version:         
Resolution:                 |    Keywords:         
----------------------------+-----------------------------------------------

Comment (by eschnett):

 Barry

 Thanks for the new patch!

 You are introducing a new "paths" syntax to the sync command. I thought
 previously that one could just list multiple machines, and simfactory
 would sync to all of them -- apparently that isn't the case, that was lost
 in translation. However, it seems that filter.cactus.rules contains only a
 list of top-level paths, and isn't supposed to contain any actual rules --
 if it did contain rules, then the result would be confusing, because "sim
 sync" and "sim sync paths" would copy and/or delete different sets of
 files. Also, people may want to change this default list of paths, so
 there should probably also be a filter.cactus.local.rules... Should this
 list of paths instead be stored in an ini file, where there is already a
 mechanism to configure settings, and where simfactory could check that
 these are actually only path names and not accidentally patterns?

 I'm also unsure about the rules:

 Shouldn't "_darcs" always be excluded, similar to CVS .svn .git .hg etc?

 What does "C" do? Does it read a .cvsignore file? If so, shouldn't this
 file be transferred as well, and be documented for simfactory? This would
 be one more configuration file for people to understand; can we ignore
 this file instead? cvs is not important any more these days.

 How do you expect people to use the "paths" mechanism? Can one give just
 top-level paths, or also directly paths deep into the hierarchy? Would you
 expect to do this regularly? If so, why? I find this somewhat dangerous,
 because people may miss transferring an updated file. Instead of telling
 simfactory what to do, the user currently tells simfactory his/her intent,
 e.g. "copy source files" or "copy parameter files", which are
 prerequisites to either building or submitting. Simfactory then deals with
 the details, ensuring things are done in a safe way. Would you find it
 inconvenient if you had to use an option to specify a pathname, e.g. "sim
 sync damiana -p par"?

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/349#comment:12>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit