FAKE template domain specific language choice

[florianbader]

Description

Adds an additional choice to the FAKE template to specify the used domain specific language. At the moment this is either the default FAKE DSL or the BlackFox DSL.

[matthid]

hehe :)
/fyi @vbfox @kblohm

[vbfox]

Nice 😉

I would prefer buildtask as a name as I don't think anyone really care about my pseudo (The name is pretty generic but I'm never really inspired with names)

[matthid]

@vbfox I guess you mean --dsl buildtask?

[matthid]

Only thing is that we could add a test for this flag (we already have some tests for the template so it should be reasonably easy to add another one), let me know if you need help.

[vbfox]

@matthid yes 😄

[florianbader]

Nice 😉

I would prefer buildtask as a name as I don't think anyone really care about my pseudo (The name is pretty generic but I'm never really inspired with names)

@vbfox I think buildtask is a bit too generic, but I also can't find a better name. Maybe blackfox might not be that bad, because it gives credit to the author ;)

[kblohm]

The names "proposed" in the original issue were "pipelines" and "target groups". I would change it to buildtask though just because the api is named that way.

[matthid]

Maybe blackfox might not be that bad, because it gives credit to the author ;)

We will see how it works it's more or less an experiment in how external modules might work (and if we can move more outside this repository) we will see how it works. We already have seen issues regarding issues with the level of binary compatibility we provide. So we might come to the conclusion that external modules are not too viable and prefer to have the code here (which I don't hope).
Anyway just something to consider

I'm pretty sure if we can come up with a good name we can still change it including the module name (if @vbfox agrees) but we shouldn't change it every version. It is indeed a bit strange to call "targets" "tasks", or is it?

[matthid]

Also It's not only "build" but also deploy and every other kind of automation ;)

[florianbader]

@kblohm Fixed your comments.
@matthid Added tests to the best of my ability. They work but I'm open for hints on how to improve my F# skills 😄

[vbfox]

We already have seen issues regarding issues with the level of binary compatibility we provide

I think it can be done especially with FAKE 5, the central API surface is quite small and easier to version. I hope it lead to FAKE packages being versionned separately with a highly compatible core and packages around it that experiment more freely.

Some things like the Record compatibility problems could even be suggested as enhancements to the F# language as it's an especially annoying point of F# APIs

I'm pretty sure if we can come up with a good name we can still change it including the module name

No problem changing it but it already changed a few times :

• The first versions used target (lowercase) as there was no strong typing, only a different declaration syntax for Target dependencies
• When typed results were added it was TypedTarget then Task because it's how gulp name them ( https://gulpjs.com/docs/en/api/concepts#tasks )
• But it colision with .Net Task and with the task CE it's not impossible to use both so when I finally decided to make a NuGet I choose BuildTask as the most unoriginal thing that removed the ambiguity

[matthid]

Some things like the Record compatibility problems could even be suggested as enhancements to the F# language as it's an especially annoying point of F# APIs

Indeed that's what I was thinking about. This is really unfortunate and not something we are able to handle at the moment

Sadly, it's the most used feature throughout all the modules, maybe with the exception of the target module. Maybe the record stuff can be solved but there are similar limitations with DUs and I don't think they are solvable by F#. In fact I doubt a lot of people can write code which we would consider 'forward compatible' ;)
But maybe time will tell us that what we do works in practice.

Regarding naming, have you tried calling your module 'Target' and hiding existing members (people can still access stuff via fully qualified names?)

[matthid]

@vbfox Maybe like this?

[matthid]

Suggested change

	- `blackfox` - Uses the BlackFox domain specific language
	- `buildtask` - Uses a string free domain specific language, called [BuildTask](https://github.com/vbfox/FoxSharp/blob/master/src/BlackFox.Fake.BuildTask/Readme.md)

[matthid]

Suggested change

	"choice": "blackfox",
	"choice": "buildtask",

[matthid]

Suggested change

	"description": "Uses the BlackFox domain specific language (see https://github.com/vbfox/FoxSharp/blob/master/src/BlackFox.Fake.BuildTask/Readme.md)"
	"description": "Uses a string free domain specific language, called [BuildTask](https://github.com/vbfox/FoxSharp/blob/master/src/BlackFox.Fake.BuildTask/Readme.md)"

[matthid]

Suggested change

	//#if (dsl == "blackfox")
	//#if (dsl == "buildtask")

[matthid]

Suggested change

	with override x.ToString () = match x with | Fake -> "fake" | BlackFox -> "blackfox"
	with override x.ToString () = match x with | Fake -> "fake" | BlackFox -> "buildtask"

[vbfox]

Regarding naming, have you tried calling your module 'Target' and hiding existing members (people can still access stuff via fully qualified names?)

I'm not a fan of hiding stuff or depending on open ordering, It's easy to miss when copy pasting code or reading someone else and make editors auto-open feature a lot less useful

[kblohm]

Just of the top of my head, for discussion purposes:

• TargetGroup
• TargetPipeline
• TargetDsl
• TargetEx (The classic)
• TargetBuilder
• TargetCe
• FakeTarget
• Task (Cake/Rake uses Task)
• FakeTask
  I would prefer something with target though, that does sound more familiar in FAKE.
  Or you could maybe just expand the Target-Module with Target.createGroup/Target.createBuilder etc.? So you dont have to hide existing ones. Or Target.Group.create/Target.FromGroup.create/Target.Builder.create, similair to Target.WithContext?

[matthid]

Afaics the implementation is not particularly related to pipelines or groups it's more accidental that it solves the same problem in a nice way. But in the end you define classical "targets" and their dependencies under the hood. You can even mix the two.

However, I feel like just calling them "Tasks" and marketing them as the new way of doing this would be fine by me as well.

Even after @vbfox I still like just 'Target' and 'TargetEx' or 'Task' from @kblohm. Additionally I'd suggest 'StrongTarget' or 'TypedTarget', 'QuickTarget' or 'BTarget' (better target or blackfox target, beta target for being second)

Yes we could also not hide but only extend the Target module, like 'createTyped' instead of just 'create' for example.

[matthid]

In the end I'd like to get something out and not wait too long on naming, as the module is external we can change naming, add a new module and not break anyone

[florianbader]

I like the idea of calling it task instead of buildtask. I'm updating the PR later so we might be able to close it for now.

[vbfox]

I like task, and would have kept it as a name if it didn't collision with a well known framework type and computation expression