Closed bartavelle closed 9 years ago
The infrastructure is in place, it's not time to classify the features ...
Oh, and to add flags to puppetresources
...
Strict is the default mode. Is that OK ? I can easily change this around (and update the README)
Even though I like Haskell, I'm a strict person. Do you think most user would want to work with the permissive mode ?
Either ways are fine to me.
I would go with permissive
as the default.
The main reason it that much of the puppetlabs modules won't work in strict mode. So unless there is a way to mark a set of modules as black sheep (without ignoring them), the tool will simply not work in strict mode as soon as you want to reuse external modules.
That said, I don't care much :-) I am trying to figure out what most users would want.
Let's go for permissive default then.
I haven't look at it closely but I found a bit weird that throwPosError
does not seem to log the position ?
Another current problem is the fact that there is no color for the warnings. Maybe we should change the warn
implementation.
Yeah the implementation might need changing so that it's more user friendly. One thing that should be kept in mind is that puppetresources
is just one use case of the library. I also would like to support server side versions, which will need to log plaintext through syslog ...
Could it be another good reason to move away from the Writer monad (which leaks anyway) and go for hslogger ? Hslogger
supports logging to syslog if I remember this correctly.
I can try this change if it is ok by you.
A server side version that would be nice ! Apparently PuppetLabs is busy rewriting the server in Clojure.
Actually, I already have some kind of server side version. The problem is that it only works with catalog compilation, and doesn't serve files yet. It is possible I start working on it soon, as I might need it.
Also, IIRC, the "Writer" part of the InterpreterMonad
is Control.Monad.RSS.Strict
, which doesn't leak and is much faster (provided by this package).
(Actually it's in the actual interpreter, InterpreterMonad
is just a ProgramT
)
Thanks for the infos. I did not realize the Writer was coming from your external package. That's cool. Do you have any idea about how to get a dependency graph from puppetresources ? Would the use of the diagram library be a good start ?
This. I even have a good commit for it ;)
I meant a way for puppetresources to display graphically the dependency graph of the puppet resources (requirements)
Oh ! Yes the diagram library might be useful, although the graphviz
binaries already solve a lot of the problems. That's the reason cabal-db
exports dot files ...
I believe the puppet master can only produce a complete dot graph (which is most of the time too cluttered).
With puppet-language
we could offer a way to "scan" deps and show them for a filtered part of the catalog. This could be really useful as a development tool.
I am unsure of what you mean. However, you might see that main daemon function gives you a function that returns the edge map, and that's the actual graph.
Ok I have just renamed m
into edgemap
for clarity sake.
Then I have realized that edgemap
is only used for exported resources or with the flag --JSON
. Is this correct ?
I am probably missing something because on my catalogs even with --JSON
enabled the array edges
seems to be empty all the time.
Any idea ?
I might be wrong but I think they are just integrated with the resources, as puppet seems to allow both ways of transmitting relationships ... but I didn't reverse engineer this, so I might be wrong.
This would allow adding features I have been reluctant to add as they are antipatterns. It is likely that a few combinators would be enough to work properly.