Hacker News Reader

Comment by mwaitjmp | Hacker News Reader

Out of interest then how do you proceed? Do you fork the code and run your own patched version?

Personally, I tend to post the change in a comment on the issue that it fixes. I don't generally bother with doing a formal PR, since that would mean setting up the repo in a dev environment, branching, etc. and would be a bunch of extra work.

Locally, I just make the change and check it in to my project.

Here's an example:

https://github.com/xwpongithub/vue-range-slider/issues/3#iss...

You can literally edit the file in github and submit a PR with a few clicks.

Every repo has different contribution rules and a one-off in one repo often just isn't worth the time to learn all the bespoke boxes that need to be checked. The work is there in the comments and if it's of value, someone more familiar can take it the last mile ... and codespaces _just_ came out generally. Could you edit online before that?

Yes, just use our own forked version.

So then when your upstream repo diverges would you just rebase and manually add in anything you want from the forked development tree on the upstream side?

Not sure what's best practice so... just curious how people have handled this - I usually leave my forks of stuff pretty stale and focus on my own little sub-pieces to achieve what I want but not too much else.

I usually have my own branch which can be used to get a diff and maintain the diff on any major code structure change. Most often there is not much hassle but can be annoying.

Yes, we would branch from upstream again and apply the patch set against the new branch. Normally it is trivial but once in a while there are manual changes necessary.

Maintaining the fork as a stack of patches using something like Stacked Git can make it a little easier than rebasing: https://stacked-git.github.io/

I do this. I wish I didn't.

First of all, building a provider isn't straightforward. The best way I've found to do this is to wrap `terraform init`, and have it `docker run` a build process for a plugin version that never existed - then dumping the built provider into the `.terraform` directory for the project. It's prone to failure; new users of the Terraform project complain that the build eats 8GB of RAM and takes many minutes.

Second, providers are constantly changing, and it's not always possible to cleanly rebase a set of community changes on top of master. Part of the trouble with letting PRs wither on the vine is that they themselves become stale - in one case, the code still compiles, but the end result is completely wrong.

For what it's worth: my use case was needing to use Terraform with some more "unusual" features of CloudFront and ALBs. The 80% use case for support is great. There's a remaining 15% that's well implemented by unmerged PRs, and another 5% entirely that's completely unsuppored. I've kept it IaC by using the `null_resource` provisioner to shell out to the AWS CLI where absolutely necessary.

heh. i've been considering a switch from ansible to terraform because i've been frustrated by ansible's limited support for some of the edge cases around ALBs. good to hear that terraform also sucks.

i'm gradually coming to the conclusion that all the tools that are supposed to make provisioning cloud infrastructure easier aren't as good as a bunch of crappy custom scripts using boto or aws-cli.

One big difference here is that while the tools might all depend on the SDK provided by the cloud, the tools themselves can also do a whole lot of good/wrong on their side. Terraform fixes a lot of that by delivering a 'standard' provider interface with normalised data formats, resource structures and encapsulation. That was pretty much a requirement for the tool to work anyway, otherwise it wouldn't have a unified way to check for configuration drift, plan changes, apply changes, do cleanups etc. You also wouldn't be able to pass data around easily (you'd end up shuffling strings around instead).

Some people prefer to do the CDK thing where you use a general programming language to synthesise the IaC stuff and then run it that way, but that doesn't really fix anything because a CDK is just built on top of the same SDK. As an added insult to injury, you now don't have a domain-specific language so save you from yourself (and your team) with all the anti-patterns you now have at your disposal ;-)

Terraform is a massive improvement over Ansible if you do anything non-trivial; even if it sucks, it sucks significantly less than Ansible at managing infrastructure resources.

I sometimes fool myself into thinking I can use Ansible in simple cases and that Terraform would be overkill but so far I've regretted those decisions every time.

Ansible wasn't designed for IaC, but configuration management, and even at that wasn't the best tool.

What made it popular was that it was easiest to start with, but that's pretty much all of its strength compared to the competition.

Ansible is sort of bad at everything, and does a few things decently.

I use it as an orchestrator / clusterssh replacement, but for configuration management it makes me nervous because I can't trust it to just not break for stupid reasons.

Last time I used it on Amazon Linux 2 with packer. It worked, but 1/3 of the time it failed with some strange error about yum database corruption.

I suspect what was happening is that Amazon Linux on start run yum to apply all available updates, and ansible was not respect yum locks, which is very surprising given that Ansible came from Red Hat so they should have known how important locking is for yum.

I ended up using salt (which has its own set of issues) and never looked back.

You can just give your self-compiled provider a different name or namespace but alias it in during normal runtime, saves a lot of grief.

You can sideload Terraform providers so you don't need to do this. I personally recommend the [implicit local mirror directory](https://www.terraform.io/docs/cli/config/config-file.html#im...) where you just place your provider in your OS's respective Terraform plugin directory (MacOS: `$HOME/.terraform.d/plugins/`).

There's other ways to sideload providers on that docs page too

Reply on news.ycombinator.com