Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider metadata object for projects in build #272

Open
oyvindberg opened this issue Jan 6, 2023 · 1 comment
Open

Consider metadata object for projects in build #272

oyvindberg opened this issue Jan 6, 2023 · 1 comment
Labels

Comments

@oyvindberg
Copy link
Owner

    > 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)./

Originally posted by @Baccata in #247 (comment)

@oyvindberg
Copy link
Owner Author

This can be a fine way of threading through whatever info you want from the build to scripts, and it can be mergeable just like the rest of the build

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant