This commit is contained in:
Joey Hess 2015-01-24 13:04:06 -04:00
parent eb3c079bba
commit 1df70ba81d
1 changed files with 16 additions and 20 deletions

View File

@ -1,17 +1,14 @@
Currently, Info about a Host's Properties is manually gathered and Currently, Info about a Host's Properties is propigated to the host by
propigated. propertyList combines the Info of the Properties in the list; examining the tree of Properties.
Docker.docked extracts relevant Info from the Properties of the container
(but not al of it, intentionally!); etc.
This works, but it's error-prone. Consider this example: This works, but there's one problem. Consider this example:
withOS desc $ \o -> case o of withOS desc $ \o -> case o of
(Just (System (Debian Unstable) _)) -> ensureProperty foo (Just (System (Debian Unstable) _)) -> ensureProperty foo
_ -> ensureProperty bar _ -> ensureProperty bar
Here, the Info of `foo` is not propigated out. Nor is `bar`'s Info. Of Here, the Info of `foo` is not propigated out. Nor is `bar`'s Info.
course, only one of them will be run, and only its info should be It's not really clear if just one Info, or both should be propigated out.
propigated out..
---- ----
@ -26,12 +23,15 @@ That is surely doable, but consider this example:
needfoo <- liftIO checkFoo needfoo <- liftIO checkFoo
if needfoo if needfoo
then ensureProperty foo then ensureProperty foo
else ensureProperty bar else ensureProperty . bar =<< liftIO (getBarParam)
In introspection mode, the liftIO is a no-op, but needs to return a Bool. In introspection mode, the liftIO is a no-op, but needs to return a Bool.
That seems unlikely (how to pick which?), but even if some defaulting is That seems unlikely (how to pick which?), but even if some defaulting is
used, only one of foo or bar's info will be seen. used, only one of foo or bar's info will be seen.
Worse, the bar property is not fully known until IO can be performed to get
its parameter.
---- ----
Another approach could be something like this: Another approach could be something like this:
@ -44,21 +44,14 @@ Another approach could be something like this:
then callfoo then callfoo
else callbar else callbar
Here withInfoFrom is able to add foo and bar's Info to the info of the Here withInfoFrom adds foo and bar as child properties of the demo property
property that (may) call them. that (may) call them.
This approach is not fully type safe; it would be possible to call This approach is not fully type safe; it would be possible to call
withInfoFrom in a way that didn't let it propigate the info. withInfoFrom in a way that didn't let it propigate the info.
Also it has the problem that it doesn't support this: And again this doesn't solve the problem that IO can be needed to get
a parameter of a child property.
property "demo" = do
needfoo <- liftIO checkFoo
if needfoo
then do
foop <- liftIO getFooParam
ensureProperty (foo foop)
else ensureProperty bar
---- ----
@ -94,6 +87,9 @@ unfinished. Most definitions of `Property` need to be changed to
`GProperty NoInfo`, so that ensureProperty can call them. It's a big, `GProperty NoInfo`, so that ensureProperty can call them. It's a big,
intrusive change, and it may complicate propellor too much. intrusive change, and it may complicate propellor too much.
I've tried to make this change a couple times now, and not been completely
successful so far.
(I may need to make instances of Prop for `GProperty NoInfo` and `GProperty (I may need to make instances of Prop for `GProperty NoInfo` and `GProperty
HasInfo`, if that's possible, and make more Property combinators work on HasInfo`, if that's possible, and make more Property combinators work on
Prop.) Prop.)