You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> How about we just establish the convention that all resource generators are passed the project name as a parameter?
Would that mean having a GeneratingScript class inherting the Script class ? That might work (from a DX perspective, that is)
passing arguments feels like programming in YAML, which is not a favourite pastime of mine.
Yeah I don't disagree there.
I'd rather that we make each script each own entry in scripts and a corresponding scala object. super clear and obvious, easy to run, easy to debug.
No configuration or flexibility, just that?
This is a little too strict for my taste, I do think it'd be interesting to allow for users to pass some configuration to the scripts in the bleep.yaml. Say someone wants to publish pre-built scripts as literal "plugins" : this would allow people to customise the behaviour of the plugin without having to touch 2 files (the build file to pull the dependency and configure a script project + a scala file).
To elaborate : if you have a metadata field in the projects configuration that'd receive an arbitrary Json object, bleep could pass that object to scripts and script implementors could use that to retrieve configuration elements however they please. If users would rather duplicate some Scala files instead of using yaml configuration, they'd totally be able to do that. What's more : you could deep-merge the metadata value of all the templates (and the one of the project itself) before passing it to the script. Imho, this would be coherent with the way bleep is configured (declaratively), generally speaking, and would prevent having to compile scala code when reconfiguring some aspects of the build (which is a one of the appeals of bleep, as having to compile a Scala-written build is detrimental to the snappiness of the build's commands)./
Would that mean having a
GeneratingScript
class inherting theScript
class ? That might work (from a DX perspective, that is)Yeah I don't disagree there.
This is a little too strict for my taste, I do think it'd be interesting to allow for users to pass some configuration to the scripts in the
bleep.yaml
. Say someone wants to publish pre-built scripts as literal "plugins" : this would allow people to customise the behaviour of the plugin without having to touch 2 files (the build file to pull the dependency and configure a script project + a scala file).To elaborate : if you have a
metadata
field in the projects configuration that'd receive an arbitrary Json object, bleep could pass that object to scripts and script implementors could use that to retrieve configuration elements however they please. If users would rather duplicate some Scala files instead of using yaml configuration, they'd totally be able to do that. What's more : you could deep-merge themetadata
value of all the templates (and the one of the project itself) before passing it to the script. Imho, this would be coherent with the way bleep is configured (declaratively), generally speaking, and would prevent having to compile scala code when reconfiguring some aspects of the build (which is a one of the appeals of bleep, as having to compile a Scala-written build is detrimental to the snappiness of the build's commands)./Originally posted by @Baccata in #247 (comment)
The text was updated successfully, but these errors were encountered: