| Re: [buckminster-dev] Action output? |
kenneth@xxxxxxxxx wrote:
I agree. It's a can of worms and your points are all very valid. Simplicity and predictability rules so all fancy stuff that I rambled about is right out. I do believe however, that specifying the output of an action might be common enough to make it worth while letting it have its own command line option and to give it a predefined property name.Question is, where do we set this <output root>? Should it be set once for the whole workspace? Or perhaps a default for the workspace and then have an option to override for each action? Should we then override just when actions are invoked or should the override be made persistent (an action <-> output root map) so that transitive invocations can be mapped on the fly?I believe a generic approach here might open up a can of worms giving more complexity than really necessary, especially if taking into account the idea of persisting roots (very easily confuses people if they don't entirely grasp that or forget it etc and why not make it possible to support many separate sets of persisted info, adding to the flexibility but also complexity). More serious problem is that there is no way we can enforce the desired behavior; for it all to work, the script-or-whatever running for an action must be 'in' on it and correctly utilize the output root.Further, if I understand your suggestion correctly, each action has their own output root. Keeping track of them all if we don't persist them is ugly for the user, providing them can be cumbersome (esp. considering a headless invocation that might want to override output roots for a number of the eventually invoked actions etc etc).I believe we simply shouldn't pursue this at this point. It's a lot more natural I think to simple leave this up to the user/designer of a given action/script - we already have the mechanism for passing in this type of information as context properties. All this makes it very clear to the user that they're responsible for two things: if they wish to support an alternate output root for their action, they must write that into the script (which they would have to do anyway), and if they want to use that, all they need is to define the prop before the action. Sounds lowtech perhaps, but it makes it very clear that there is a relationship between the script and the setting. Consider a script that doesn't understand that they've been given somewhere else to put their results and they won't care a bit that the user told buckminster to 'put your files here'...Finally, consider that there are cases where an extra 'output root' isn't what you're really after. Consider, say, a 'deploy' action for a complex product; deployment is actually done by contacting 3 different machines remotely and downloading individual parts of the products to them, running commands etc etc. In that case, there's a great deal of things that could be abstracted in the script driving the 'deploy' action; 'output root' wouldn't make much sense to that action, and in this context 'output root' is just a very, very special case of influencing an action script beyond the basics.As an aside, it obviously makes sense to help with persisting a group of props to use - in the headless case we should obviously support not only the --define for individual props, but also a --definefile or similar, and in the UI something similar.What do you think?
I'm currently improving the feature.xml based CSpec builder. It needs to generate a 'create.feature' action that makes sense. When building a feature I think the sensible thing would be to put the resulting features and plugins under some specific directory outside of the feature that you build. It can be solved by using a property like you suggest, but I'm reluctant to do that. A property is easily misspelled, it doesn't turn up in a help for the perform command, etc.
So what if we just strip off all fancy stuff that I proposed originally and just keep a --output command line option to perform? It would then map to the predefined property 'buckminster.output' for all actions. It may of course be ignored too, that's up to the actor implementation but we would establish a little more then just a convention and it would be a bit more user-friendly.
Regards, Thomas Hallgren