bindl generate make targets should verify that Bindl exists

[chrisyxlee]

The Problem

Usually 1 person will set up Bindl for the project. Other members of the project will only care about the dependency that they're using (i.e. bin/ko) but won't care for how it's getting downloaded or updated.

The erroneous flow I see is

1. I swap a project over to Bindl.
2. Teammate tries to install bin/ko
3. Teammate runs into issues since they don't have Bindl.
4. Teammate reaches out to me to figure out how to get Bindl to work.

Solving this problem removes a step that will be easily forgotten and explicitly sets Bindl itself as a dependency.

My Current Workaround

I manually modified the generated file that says "DO NOT MODIFY".

One Option I Was Thinking Of

Either through bindl.yaml or through commandline. I was thinking of an optional flag. The target would need to be defined by the user (unless #13 is implemented).

Current

# THIS FILE WAS GENERATED BY BINDL 0.0.5 (4b5fba05cd01309ca791844d65e97a3309b7ec0d) (go1.18) ON 2022-04-20T22:36:26Z
# DO NOT MODIFY - ANY MODIFICATIONS WILL BE OVERWRITTEN

# For this file to work appropriately, bindl must already be setup in the machine
# through bootstrap or other mechanisms.

BINDL_PROGRAMS?=$(shell bindl list --oneline)
BINDL_PROGRAMS_PATH?=$(addprefix bin/,$(BINDL_PROGRAMS))

.bindl-lock.yaml:
	bindl sync

# On the other hand, lockfile is a regular pre-requisite where we would like for
# programs to be re-validated if lockfile was modified, in case the versions have changed.
$(BINDL_PROGRAMS_PATH): .bindl-lock.yaml
	bindl get $(@F)

Feature Request

# THIS FILE WAS GENERATED BY BINDL 0.0.5 (4b5fba05cd01309ca791844d65e97a3309b7ec0d) (go1.18) ON 2022-04-20T22:36:26Z
# DO NOT MODIFY - ANY MODIFICATIONS WILL BE OVERWRITTEN

# For this file to work appropriately, bindl must already be setup in the machine
# through bootstrap or other mechanisms.

BINDL_PROGRAMS?=$(shell bindl list --oneline)
BINDL_PROGRAMS_PATH?=$(addprefix bin/,$(BINDL_PROGRAMS))

.bindl-lock.yaml: bin/bindl
	bindl sync

# On the other hand, lockfile is a regular pre-requisite where we would like for
# programs to be re-validated if lockfile was modified, in case the versions have changed.
$(BINDL_PROGRAMS_PATH): .bindl-lock.yaml bin/bindl
	bindl get $(@F)

[wilsonehusin]

Does make show a different error message with the new dependency? Because it would end up being a recursive rule (bin/bindl qualifies under $(BINDL_PROGRAMS_PATH)).

Previously the dependency was there, but I removed it because in the event bindl was not bootstrapped, the error message wasn't clear.

I think the alternative that we can do is to do something like this:

bin/bindl:
	curl --location https://bindl.dev/bootstrap.sh | bash

.bindl-lock.yaml: | bin/bindl

(notice the pipe in the rule, which denotes order-only pre-requisite)

[chrisyxlee]

Because it would end up being a recursive rule (bin/bindl qualifies under $(BINDL_PROGRAMS_PATH)).

😵‍💫 I see what the issue was now.

A thought though -- what if instead of making a fully globbing make target, Bindl explicitly updates the Makefile.bindl as well everytime (if specified in bindl.yaml)?

I still have some binaries that I need to install (not through Bindl) that I would like to keep in bin/, so it would make sense for the make targets to be specific to what Bindl has control over.

Downside is that this solution would make bindl gen make implicitly part of bindl get.

[wilsonehusin]

Downside is that this solution would make bindl gen make implicitly part of bindl get.

Since we're not expecting users to always use Makefile (because we don't want hard dependency on Makefile), this flow would need to go through "after bindl get, if Makefile.bindl exists, run bindl gen make".

Another layer of complexity would be people not using Makefile.bindl name but instead bindl.mk 🙃

Let's talk about this more broadly and less prescriptive: what user experience do we want? If I'm following correctly, I would translate the discussion above into "bootstrapping experience", specifically "how can Bindl feel transparent and integrated to users, such that they don't need to care about Bindl". Does that align with what you're thinking?