search

paluh / ansible-augeas

Ansible module for augeas
Other
88 stars 17 forks source link

Working with this module prompted several ideas for me. #13

Open adamryczkowski opened 8 years ago

adamryczkowski commented 8 years ago

Now I know its structure, I am thinking about re-factoring it a little:

  1. First of all, I think the module should take structured input, rather than parse the "commands" strings itself.
  2. I think that rather NO_MODL_AUTOLOAD should be default. I can't imagine why would someone a) pay a very heavy price for loading all lenses, when all is needed is access to one file, b) Knowledge which specific lens someone use is very important; I know that augeas wants us to believe that data representation should be independent of the lens choice, but that is in my opinion a myth. Lenses' authors have a lot of freedom in designing the data structure. I believe it should be mandatory to state the lens explicitly, just like the location of the configuration file.

What do you think? Do you want to talk about it? I can program the module myself with D, or we can join our forces and enhance your module, but I would need some help in designing the structure of the code from someone who has some experience with Python. My way of thinking about programming might be incompatible with the spirit of interpreted scripts :-).

paluh commented 8 years ago
  1. First of all, I think the module should take structured input, rather than parse the "commands" strings itself.

This is the ideal approach for me too, but I wasn't able to come up with any sensible way to pass multiple commands through ansible parameters, so I ended up with structured API for a single command invocation only and with commands string parsing for augeas "session". I'll be really happy to drop this pseudo "parsing" from this module ;-)

  1. I think that rather NO_MODL_AUTOLOAD should be default. I can't imagine why would someone a) pay a very heavy price for loading all lenses, when all is needed is access to one file, b) Knowledge which specific lens someone use is very important; I know that augeas wants us to believe that data representation should be independent of the lens choice, but that is in my opinion a myth. Lenses' authors have a lot of freedom in designing the data structure. I believe it should be mandatory to state the lens explicitly, just like the location of the configuration file.

I think, that this is really nice idea, to add lens option (which comes NO_MODL_AUTOLOAD optimization) to the module API, but I'm not sure if this should be required parameter. Maybe we can make it optional? This idea has additional benefits - for sure we can improve error reporting we this approach.

What do you think? Do you want to talk about it? I can program the module myself with D, or we can join our forces and enhance your module, but I would need some help from someone who has some experience with Python.

Unfortunately I'm during deployment and integration phase of quite big project now, and I'm not sure if I can really help with above changes during next two weeks. I will try. Regarding Python I think that I can help, but I'm not sure if I can say that I really know Python and I write really idiomatic and correctly structured code. Additionally, in case of ansible module writing, I think that it had really terrible API when I have been starting work on this module:

I'm not sure what has changed since then, but probably this ecosystem is much better place now and there are better solutions for this problems. If you care about code quality and want to make such a big refactoring, I think that we should at first improve whole module structure according to latest ansible API. I hope that with these changes it will be possible to write some proper tests.

P.S. As a side "programming language" note I want to point out my small summer project (https://github.com/paluh/propellor-augeas/blob/master/src/Propellor/Property/Augeas.hs) where I've wrapped rough haskell augeas bindings in more pleasant API. It is really pleasant to write such a DSL in haskell - you can easily get full control over complete execution context and flow of your API... but haskell has other drawbacks for me... ;-)

adamryczkowski commented 8 years ago

I just started to write a D bindings for augeas as well (it is not published yet). So far, everything works and I am tempted to try writing the whole ansible module in D. (With D you can write very similar and concise code to Python + you get all the benefits of statically typed language. )

paluh commented 8 years ago

I just started to write a D bindings for augeas as well (it is not published yet). So far, everything works and I am tempted to try writing the whole ansible module in D. (With D you can write very similar and concise code to Python + you get all the benefits of statically typed language. )

Nice! I will check your module for sure - I'm really interested to see how you are going to structure its API... and get a taste of D of course ;-) Maybe I will adapt some ideas into this implementation or drop it all together ;-) Good Luck!