Cryptic error on opening Sim with conflicting name with file in working directory

[cing]

Just a little better error handling is needed here, or well, you could support Sims with the same path name as files but that could get really confusing!

In shell:

touch marlar

then in Python,

from mdsynthesis import mds
s=mds.Sim("marlar")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.macosx-10.5-x86_64/egg/mdsynthesis/containers.py", line 512, in __init__
  File "build/bdist.macosx-10.5-x86_64/egg/mdsynthesis/containers.py", line 224, in _regenerate
  File "build/bdist.macosx-10.5-x86_64/egg/mdsynthesis/core/persistence.py", line 65, in containerfile
UnboundLocalError: local variable 'statefileclass' referenced before assignment

[dotsdl]

Ah...I think this is one of perhaps quite a few cases where we expect Containers should work a certain way, but due to their simple __init__() rules, probably don't yet. I think it's worthwhile to lay out all the ways we can think of for initializing Containers, both from scratch and when regenerating them. I could add a fix that includes this case, but I'm curious if we can try and identify any others, too, to make it less of a band-aid and more of a settled specification.

For generation, these should work:

1. Sim('name'), where 'name' is not an existing file or directory in the current directory
2. Sim('name'), where 'name' is an existing directory without any state files already present
3. Sim('name', location='somedir'), where 'name' is not an existing file or directory in 'somedir'
4. Sim('name', location='somedir'), where './somedir/name' is an existing directory without any state files inside

For regeneration, these should work:

1. Sim('name'), where there exists only one Sim state file inside './name'
2. Sim('name/Sim.<uuid>.h5'), where there need not be only a single Sim state file in './name'

Everything else should fail with an exception indicating that no state file was found. I think that will tie up all the possibilities. Am I missing something?

[dotsdl]

This has been addressed in datreant/datreant#14. The location keyword has been ditched in favor of using the first argument to the constructor to specify the statefile location in every case.

For generation, these will all work:

1. Treant('treant'), where 'treant' is not an existing file or directory path
2. Treant('treant'), where 'treant' is an existing directory without Treant state files inside
3. Treant('/somedir/treant'), where 'treant' is not an existing file or directory in 'somedir'
4. Treant('/somedir/treant'), where 'treant' is an existing directory in 'somedir' without any Treant state files inside
5. Treant('somedir/treant', new=True), where 'treant' is an existing directory in 'somedir' with or without an existing Treant statefile
6. Treant('/somedir/treant'), where 'treant' is an existing directory in 'somedir' with other types of Treant files inside (such as a Group)

For regeneration, these will all work:

1. Treant('treant'), where there exists only one Treant state file inside 'treant'
2. Treant('treant/Treant.<uuid>.<ext>'), where there need not be only a single Treant state file in 'treant'

[cing]

Well done! You're really putting in some awesome work on this.

[dotsdl]

@cing thanks! Getting close to a new release, so trying to tie up important issues.