Configfile structure.

[Samuel Ytterbrink]

Hi every one!
I'm happy to see that my changes have been added to the default branch
of the 'main' repository.
Now we can start building the configuration file support! Yeahy!
My proposal is that every class in the source gets there own
config-section. And that they implement there own way to configure
themselfs, and also implements how to write them selfs to a config
file.
then we could create a way to finde these clases and build oure parser
dynamically and be able to create features more easily. Also i think
that we should build the argument parser the same way.

I can see 2 problems with this:

* Some of the will have more then 1 instance, could be solved with
name conventions.
* A lot of refactoring will be required if we found out that the
interface for building and saving config files is to weak.

example
[base]
gui = TkGUI
engine = Pytddmon

[Pytddmon]
test_strategies = RecursiveRegexpTestStrategy~1, RecursiveRegexpTestStrategy~2

[RecursiveRegexpTestStrategy~1]
root = .
expr = "test_.*\\.py"

...etc

class Pytddmon(object):
@classmethod
def from_config(cls, section, config):
test_strategies = []
for new_section in config.get(section, "test_strategies").split(","):
test_strategies.append(
get_class_by_section_name(new_section).from_config(new_section, config)
)
return cls(test_strategies=test_strategies)

--
//Samuel Ytterbrink

[Olof Bjarnason]

Hmm. Interesting idea to spread the config functionality.

But before we discuss a technical solution, I think we must agree at
what needs to be configurable and what is nice to be configurable.

You solution answers that question with "everything should be
configurable" which I think is too much :)

2011/11/9 Samuel Ytterbrink <nep...@gmail.com>:

[Samuel Ytterbrink]

well, i think that every thing that is a argument to a constructor
should be a config option.

2011/11/9 Olof Bjarnason <olof.bj...@gmail.com>:

--
//Samuel Ytterbrink

[Olof Bjarnason]

2011/11/9 Samuel Ytterbrink <nep...@gmail.com>:

> well, i think that every thing that is a argument to a constructor
> should be a config option.

Well, that is a very programmer-oriented viewpoint; instead think of
what users of pytddmon wants to be able to configure.

For example, shutting off the flashing, changing the test file pattern
and the like.

In other words - what do you, as a user of pytddmon - want to be able
to configure?

[Samuel Ytterbrink]

well i think that the blinking should be a parameter to the TkGUI
constructor!? And as one of the users i _want_ to configure every
thing. Why? well i you remember we where talking about using the
config files as setup for systests. The more we put into the config
files the more workarounds we will be needing to do.

What i think we should have is shortcuts( very pythonic) to create
common cases of configuration.

[defaults]
static_test_set = "test_mytests.py"
static_file_set = "main.py"

2011/11/9 Olof Bjarnason <olof.bj...@gmail.com>:

--
//Samuel Ytterbrink

[Rafael Capucho]

Hello!,

I see a problem here,

If we make our config file looking for methods constructor we will stay with dependencies about this mothods.

In other words, if we make some refactor in the source project (that happen often) we will change the config structure.

It's do not follow an pattern as you can see.

Configure inputs should be in the documentation, but if we change this for each refactory the users will not like this.

Specially because will break they config file.

I believe that the Samuels viewpoint is good, but with the changes in the sourcecode it'll be hard to maintain.

What do you think?

Best Regards.

[Samuel Ytterbrink]

i think still that looking for class names is okey and i don't believe
in scanning methods, that is to hard/evil ^^.
Also in the example code i use a function to actually finde the class,
so its only a convention that the names must match.

We cpuld have a nother system whit similar results:

class MyModuleThatHasAChangingName(object):
conf_name = "very_easy_and_readable_name"

2011/11/9 Rafael Capucho <rafael....@gmail.com>:

--
//Samuel Ytterbrink

[Olof Bjarnason]

I think Rafael has a good point here - I see not stopping at the
refactoring efforts being done to pytddmon, with Samuel on the team :)

Samuel - I can see systest-generalisation as clear use case for the
config file (even if it is a very special pytddmon user role that
wants to use systests, namely we the developers of pytddmon), but then
I think it is fair to ask of some examples of systests you could write
with your idea in mind, that we cannot write today.

Can you give 2-3 examples of systests (in english, not code), that
would be possible with the "per-class config mechanism" in place?

2011/11/9 Samuel Ytterbrink <nep...@gmail.com>:

[Olof Bjarnason]

2011/11/9 Olof Bjarnason <olof.bj...@gmail.com>:

> I think Rafael has a good point here - I see not stopping at the

"not" should have been "no", sorry for double-posting