Threads for k0kada

  1. 7

    I feel like Python is the only language where I see posts like this. I think a big reason is that most Python code does not use any of the newer features anyway, so there’s no carrot to upgrade, only stick.

    1. 5

      Well, the latest release bought some very nice performance improvements:

      Also, Node and Ruby (that are the other “big” interpret languages used nowadays) also have big releases breaking things and nobody seems to care that much. Not sure why the issue is only with Python, maybe because it is used in more contexts where people are not “engineers” (e.g.: scientific communities).

      1. 4

        I think a big reason is that most Python code does not use any of the newer features anyway

        Speaking as someone who’s been involved in a very popular Python package (Django): it’s more complex than that.

        Python does yearly feature releases and a five-year support cycle for each one. So, suppose that a useful bit of new syntax gets introduced in Python 3.12. It’s not available in, and in fact is a syntax error in, Python 3.10, 3.9, 3.8, etc.

        Which means that if you’re a package maintainer who wants to stay compatible with the full range of upstream supported Python versions, you are always five years behind the state of the art and people take jabs at you on internet forums for not adopting new features. But if you break compatibility early to adopt the feature, people take jabs at you on internet forums for forcing unnecessary “make work” upgrades on everyone.

        Python 3.7’s end of support will allow big packages to finally start adopting Python 3.8 features: audit hooks, the walrus operator, positional-only parameters. But even newer things like pattern matching – a huge feature in Python 3.10 – won’t be generally usable by big packages until sometime in late 2025 due to having to wait until Python 3.9 falls out of support.

      1. 4

        I use NixOS/home-manager for a few years already with a similar objective (managing multiple “pet” systems). Just a quick comparison between the two (based on the Design Overview from README):

        • Runs locally on a single machine: # pets -conf_dir /etc/pets vs # sudo nixos-rebuild switch --flake /etc/nixos#hostname
        • One directory holds the full configuration of the system: /etc/pets vs /etc/nixos
        • No variables, no templates, just plain static config files: Nix DSL supports all of those
        • No dependencies between different components: vs Nix DSL allow this if you need
        • A single one-shot program reading the configuration directory and applying changes: pets vs nixos-rebuild (however you also need to learn the other nix commands for special purposes, and it is kinda messy right now)
        • Changes are applied only if basic syntax checks pass: also valid for Nix
        • Main interaction mechanism inspired by vim modelines: vs Nix has its own DSL

        Now, I am not trying to detract of the approach. In general this seems like an interesting project, but in my years of experience of managing “pets”, one thing that I sorely missed was a template system. In most cases I want to share 99% of my configuration in all my systems, but it is the remaining 1% that is not shared that gets tricky.

        Some programs like your $SHELL allow you do to it since the configuration language is the same as the scripting language, so you can pretty much write some code that allow you to load configurations e.g. per hostname. However some less flexible configuration formats doesn’t allow it at all, and this is where having a template system helps.

        Before using Nix I used GNU Stow for the same purpose, started to write my own template system, almost switched to Ansible (that is designed more to manage “cattle” systems) before switching to NixOS (and eventually home-manager), the last one gave me templates for free (and of course many more features).

        I am deeply invested in the Nix ecosystem to change right now and I really like the experience even with the rough edges, but at least for my use cases I wouldn’t use this project because of the lack of templates.