This repository was archived by the owner on Jun 26, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 26, 2024. It is now read-only.
bindl generate make targets should verify that Bindl exists #73
Description
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
- I swap a project over to Bindl.
- Teammate tries to install
bin/ko - Teammate runs into issues since they don't have Bindl.
- 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)
Activity
wilsonehusin commentedon Apr 21, 2022
Does
makeshow a different error message with the new dependency? Because it would end up being a recursive rule (bin/bindlqualifies under$(BINDL_PROGRAMS_PATH)).Previously the dependency was there, but I removed it because in the event
bindlwas not bootstrapped, the error message wasn't clear.I think the alternative that we can do is to do something like this:
(notice the pipe in the rule, which denotes order-only pre-requisite)
[-]Allow `bindl generate make` to take in a separate Makefile target (for getting Bindl)[/-][+]`bindl generate make` targets should verify that Bindl exists[/+]chrisyxlee commentedon Apr 21, 2022
😵💫 I see what the issue was now.
A thought though -- what if instead of making a fully globbing
maketarget, Bindl explicitly updates the Makefile.bindl as well everytime (if specified inbindl.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 themaketargets to be specific to what Bindl has control over.Downside is that this solution would make
bindl gen makeimplicitly part ofbindl get.wilsonehusin commentedon Apr 21, 2022
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, ifMakefile.bindlexists, runbindl gen make".Another layer of complexity would be people not using
Makefile.bindlname but insteadbindl.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?