Open pauldotknopf opened 7 years ago
I love Cake as well as the concept behind Frosting. That said, I think it's out of scope for Wyam. Even though we've got tons of modules for all kinds of things and there are plans to greatly expand the set of recipes, everything is in the service of performing static generation. While Cake works fantastic as an orchestration tool around setting up the static build and deploying it when done, I don't want those concerns to get mixed in directly with Wyam.
Even though I don't think something like Frosting (or even Cake directly) is appropriate for usage baked into (zing!) Wyam recipes, that doesn't mean there isn't value in explaining how that integration could work out-of-band. I think it would be great to get some tutorials and examples showing how this could be accomplished. Third-party recipes that do integrate with Cake directly also aren't out of the question.
I don't want those concerns to get mixed in directly with Wyam
I agree.
IMO, I don't like how Wyam currently using Cake with recipes and NuGet references. It seems like too much infrastructure for what is really a simple static file generator.
Even though I don't think something like Frosting (or even Cake directly) is appropriate for usage baked into (zing!) Wyam recipes
The only reason I brought this up is because of the plans (I think) to eventually support .NET Core. It seems that Cake is going this route for .NET Core runners. Do you plan on just supporting mono using the old .cake files?
IMO, I think more focus should be on executing and orchestrating recipes/pipelines from an API. Currently, there is a lot of setup to start a generation, where as there could be something like:
var result = Wyam.Generate()
.WithRecipe(x => x.Blog())
.WriteTo("somewhere")
.Run();
Then .cake files and frost can be all out-of-band, separate repos, etc.
Just my thoughts/opinions, however useless ;)
Just my thoughts/opinions, however useless
Never useless! I rely very heavily on input from the community and have been known to totally change direction based on little feedback.
I don't like how Wyam currently using Cake with recipes and NuGet references
Cake isn't currently required at all, though it does make a nice build orchestrator. Can you elaborate on this part a little bit? What about the current setup don't you like? Is it too hard to run a recipe without Cake? And what was meant by NuGet references - you mean how you need to add #n
directives to bring in the module packages for particular modules?
I think more focus should be on executing and orchestrating recipes/pipelines from an API
You can actually do that today. Using Wyam as a library directly in your custom application is totally supported (though not well documented yet). See here for a little info: https://wyam.io/docs/usage/embedding. The idea is that you use Wyam via the Wyam.Common
and Wyam.Core
packages and create an instance of the Engine
. From there you can fully control the build process from within your application. There's at least one user I know of that's taken a liking to running Wyam from inside LINQPad using this approach.
I don't like how Wyam currently using Cake with recipes and NuGet references.
What I mean to say is that, I think the Cake support for Wyam should be more out-of-band than it is currently. I believe that is the biggest piece that is preventing .NET Core support. I'd like Wyam to support .NET Core and mono, but if you use the Cake stuff, you must use mono (since that is what Cake uses). I feel like Wyam should have all the libraries support .NET standard, with a separate repository for "Wyam.Configuration" (maybe call it Wyam.Cake), which references Wyam via Nuget, and adds the custom Cake orchestration support.
Also, since I know Cake, It is hard to determine where Cake ends, and where Wyam begins. What about parameters, and using the Arguement
method from Cake? What if I want to orchestrate Wyam from within a normal Cake build script? I notice your build process simply invokes wyam.exe from within a normal cake script, but again, I think Wyam.Cake (formerly Wyam.Configuration) should have the custom Cake stuff, and maybe some additional commands/aliases for using Wyam in traditional Cake scripts.
As for using it at the api level, I get that it works, and I have used it, but it is far from first-class. Things aren't "Fluently", like adding recipes, and the paths (and path order) took a lot of debugging to get right to work with themes (which also had to be massaged a little, with referenced NuGet theme packages not adding content to project). I understand no documentation, but I think there should be more focus from running this from an API level.
I think the focus should be API first, and then Cake/CustomCake/Frost should be separate repos which inherit whatever limitations those platforms impose.
What are your thoughts on this? Is it on your radar for usage in your recipes?
https://github.com/cake-build/frosting