docs: add makefile improvement proposal

[isubasinghe]

Signed-off-by: Isitha Subasinghe [email protected]

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a mentoring request, please provide an update here. Thank you for your contributions.

[rohankmr414]

@isubasinghe I'd suggest we also try experimenting with Vagrant. It is used to spin up isolated development environments inside VMs or docker, the config for that will be stored in the repo in a file named Vagrantfile.

[isubasinghe]

Thanks for the review @caelan-io , addressed the feedback.

[alexec]

Getting started is a real issue. I think think the right solution, because we're on Github, it Codespace. Have you experimented with that?

[isubasinghe]

@alexec I think that works as well but I think having Nix could be in addition to that to provide a better build experience on local machines.

I think I can get a Nix file up such that the dependencies we use will be the exact same for everyone, I don't think I even have to modify the Makefile for this. This alone should solve most of the issues I've had in the past with getting Argo Workflows running on Fedora.

[alexec]

1. I agree that the Makefile today is too complex. It has many options that are not used and could be simplified removed, e.g. KUBERNETES_NAMESPACE.
2. Let's use DevContainers for the tooling. This is much more mature that it was 1 years ago and is now usable.
3. Let's avoid any tools that are programatic in nature rather than declarative. They're always harder to understand, which results in a weaker eco-system, and less popularity and adoption. I've not heard of Nix or Devenv, but we already have a toolchain.

@isubasinghe if you're interested, I can list out the improvement we could make to the Makefile to reduce it complexity and rely more on the underlying tools.

I don't think we need PR for proposals to build tool chains. Let's open an issue instead.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a mentoring request, please provide an update here. Thank you for your contributions.

[caelan-io]

Thanks @alexec - yes if you're able to list out the improvements you have in mind, we can make the changes:

I can list out the improvement we could make to the Makefile to reduce it complexity and rely more on the underlying tools.

I don't think we need PR for proposals to build tool chains. Let's open an issue instead.

@isubasinghe opened this proposal at @sarabala1979 's request. Can we keep the discussion thread going here until we have another PR opened?

[isubasinghe]

@juliev0 As a general comment, we can keep the Makefile, I suggest Nix as an additional option to make life easier for people who are not on OSX/Ubuntu or just want a reproducible build environment. I strongly believe the two can co-exist.

[isubasinghe]

@isubasinghe I'd suggest we also try experimenting with Vagrant. It is used to spin up isolated development environments inside VMs or docker, the config for that will be stored in the repo in a file named Vagrantfile.

@rohankmr414 Sorry, I forgot to reply. But yeah I think we can have a look at this as well. I also think it might be trivial to create a VM image from this Nix file itself. See this https://github.com/nix-community/awesome-nix#virtualisation. It seems to support firecracker to run NixOS VM's

[juliev0]

I don't think we need PR for proposals to build tool chains. Let's open an issue instead.

@alexec Isitha opened up a PR for this proposal because it's more likely to get seen by more people and by folks like you than opening an Issue. Also, I had mentioned that this was the way to go. I was originally told to put the ArtifactGC proposal in this same directory. As I recall, this is what Argo CD is doing.

Also, Isitha opened up a PR for Nix. It sounds like it would address the big hurdles of devs getting started on non OSX/Ubuntu. And it sounds like it would not affect the current processes for those who want to use it. Any reason in that case not to merge it? I know you mentioned an alternative strategy, so if you feel that that should be put in place instead please provide the details. Thanks.

1. I agree that the Makefile today is too complex. It has many options that are not used and could be simplified removed, e.g. KUBERNETES_NAMESPACE.
2. Let's use DevContainers for the tooling. This is much more mature that it was 1 years ago and is now usable.
3. Let's avoid any tools that are programatic in nature rather than declarative. They're always harder to understand, which results in a weaker eco-system, and less popularity and adoption. I've not heard of Nix or Devenv, but we already have a toolchain.

@isubasinghe if you're interested, I can list out the improvement we could make to the Makefile to reduce it complexity and rely more on the underlying tools.

[terrytangyuan]

One concern is that a lot of the commands seem to duplicate what's in Makefile. If we can somehow refactor that it would be great since this will double maintenance effort. An example: #10999 (comment)

[isubasinghe]

One concern is that a lot of the commands seem to duplicate what's in Makefile. If we can somehow refactor that it would be great since this will double maintenance effort. An example: #10999 (comment)

This is very much intentional and a feature of nix, the build system is sealed from the rest of the environment. This is what gives us reproducible builds.

I agree that this increases maintenance effort, I offer three solutions for this:

1. Sidestep this entirely and say Nix is an unofficial feature we support.
2. Base the Makefile off the dependencies installed via Nix.
3. The Makefile doesn't change at a dramatic pace, I can update the file whenever needed.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a mentoring request, please provide an update here. Thank you for your contributions.

[JPZ13]

Not stale

[juliev0]

since we already merged the actual work, I can enable auto-merge for this