Show HN: Updatecli – What if Dependabot and Ansible had a child?

I look forward to trying this with gitea to automatically create pull requests to update ansible plays with the latest version of software.

With Meta Package Manager you can aggregate the results of all package managers available on your machine:

    $ mpm outdated
    ╭──────────────┬─────────────┬─────────┬───────────────────┬────────────────╮
    │ Package name │ ID          │ Manager │ Installed version │ Latest version │
    ├──────────────┼─────────────┼─────────┼───────────────────┼────────────────┤
    │ curl         │ curl        │ brew    │ 7.79.1            │ 7.79.1_1       │
    │ git          │ git         │ brew    │ 2.33.0            │ 2.33.0_1       │
    │ openssl@1.1  │ openssl@1.1 │ brew    │ 1.1.1l            │ 1.1.1l_1       │
    │ rake         │ rake        │ gem     │ 13.0.3            │ 13.0.6         │
    │ Telegram     │ 747648890   │ mas     │ 8.1               │ 8.1.3          │
    │ npm          │ npm@8.0.0   │ npm     │ 7.24.0            │ 8.0.0          │
    │ pip          │ pip         │ pip     │ 21.2.4            │ 21.3           │
    │ regex        │ regex       │ pip     │ 2021.9.30         │ 2021.10.8      │
    ╰──────────────┴─────────────┴─────────┴───────────────────┴────────────────╯
    8 packages total (brew: 3, pip: 2, gem: 1, mas: 1, npm: 1, apm: 0, cask: 0, composer: 0).

(edit: formatting)

"Sources": what does this do? Collect information. This doesn't need to be a particular program, this could just be a data specification that any program could generate data according to the spec. Thus you could have a dozen different programs that could each generate the spec.

"Conditions": This also doesn't need to be a dedicated program. Any program that can read the data specification can have one or two lines of simple logic; a couple lines of shell script would work fine. For complicated conditions you could use a more complex language, or build applications with specific features that are needed often.

"Targets": This part seems a little complicated, could use deconstructing a bit more. If you want to modify a YAML file, that is one dedicated kind of action to take. If you want to commit that file to a Git repo, that's another action. Opening a PR is another action (PRs aren't a Git primitive). Those three things could be separated but run one after another, all as separate programs.

The plugin aspect is certainly useful for being able to share pre-made solutions. But those "plugins" don't need to be strongly coupled to a monolithic application. Drone.io is a fantastic example of a loosely-coupled cloud-native design; every plugin is actually a Docker container, which is just an abstraction around arbitrary applications that uses environment variables and command-line options. (Also, the data specs absolutely needs a version number, and should consider backwards compatibility)

I'd guess I'm missing something in that question?

I didn't study the docs to know how much this is on the "ansible" side of things, where conditions can be almost anything, and thus describing possible legal values would be some monster work

Anyway, looks really cool. Dependabot seems to some strange limitations, and I'll probably look into using this.

Out of curiousity, how are you linked to the Jenkins project? Are you just an OSS contributor or do you do this full time?

Nope. Nope, nope, nope.

I know a lot of people, including myself, who hates YAML with a passion.

First, they hate the format itself. It's very easy to introduce hard-to-find typos. Plus it has multiple versions, no way to tell which one you use, and depending of the parser that ends up eating the file, you may get weird results. It's way worse then just the "Norway problem". Typically, a bad monday morning could look like this:

    >>> import yaml
    >>> yaml.safe_load(''' 
        port_mappings: 3333:33
        alternative_port_mapping: 3333:33,
        countries: [FR, US, UK, NO, IT] 
        1 : 1,0
        2: 01
        3: 1.0
        4: 1O
        5: 0b1
        6: 0x1
        7: 0i1
        8: hey,
        8.0: oh,
        version: [3.1, "3.1", 3.10, "3.10"]
    ''')

    {
        'port_mappings': 200013,
        'alternative_port_mapping': '3333:33,',
        'countries': ['FR', 'US', 'UK', False, 'IT'],
        1: '1,0',
        2: 1,
        3: 1.0,
        4: '1O',
        5: 1,
        6: 1,
        7: '0i1',
        8: 'oh,',
        'version': [3.1, '3.1', 3.1, '3.10']
    }

But worse, YAML is mostly declarative, so no complex system can be described in it. Here we come to the second reason people may hate it: it's usually turned into an even worse DSL.

A very limited, badly designed, half documented and tested DSL with almost no tooling to write or debug the stuff. And each project has a different DSL, of course.

Take Ansible. If your playbook is more than 10 lines, it becomes a pain to write because you are basically using a programming language embedded into a markup language. You have no print() or breakpoint to dive into the mess it does. It has to reinvent ways to pass values around since there are no functions with references to parameters nor return values.

Mind you, this DSL calls Python under the hood, so they could have just exposed a declarative, idempotent Python API, but no. The entire world was required to recreate syntax highlighting, snippets, go-to-definition and so on for it. Which will never be good compared to the infra for real languages.

There are few reasons to decide to use YAML, apart from "this is the only rich format supported out of the box by this system that has comments". Which I totally get, but still.

If one can, use JSON, TOML or XML depending of the case, if we need only values.

And if we need more than values, let's either define a clean, restricted API with a full blown programming language, or, if the use case requires it, use CUELang (https://cuelang.org/).

CUELang is cleaner than YAML on all points, even for just data. It can provide a schema, can validate the data with that schema. It can embed logic. It can import and export from YAML and JSON so you stay compatible with the entire devops world.

And it's not Turing complete, but has useful constructs to repeat, branch and reuse code.