• Kogasa@programming.dev
    link
    fedilink
    arrow-up
    25
    arrow-down
    18
    ·
    1 year ago

    Those bugs and PRs would just get closed without comment. Nobody is going to move a dotfile as a breaking change in any established software. You either get it right the first time or probably never.

    • nous@programming.dev
      link
      fedilink
      English
      arrow-up
      34
      arrow-down
      1
      ·
      1 year ago

      The software can read from both locations in a backwards compatible way. Many tools already do this.

      • CosmicTurtle@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        4
        ·
        1 year ago

        The best way to handle this is to have the next version move the old directory (if it exists) and then start reading from there.

        That way it’s in compliance from then forward.

        A UI notice is nice but will probably be ignored.

        • donnachaidh@lemmy.dcmrobertson.com
          link
          fedilink
          arrow-up
          11
          ·
          1 year ago

          That could break some peoples’ dotfile management, e.g. symlinks or git repos. I’d say deprecation notice and reading from both, at least for a while, is better.

    • duncesplayed@lemmy.one
      link
      fedilink
      English
      arrow-up
      24
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Nobody is going to move a dotfile as a breaking change in any established software

      We have oodles of counterexamples to this. GIMP did it, Blender did it, DOSBox did it, Libreoffice did it, Skype did it, Wireshark did it, ad nauseum. It’s not really as big a deal as you make it to be (or a big deal at all). You have a transitional period where you look for config files in both locations, and mark the old location as obsolete.

      • Kogasa@programming.dev
        link
        fedilink
        arrow-up
        9
        arrow-down
        2
        ·
        1 year ago

        It’s not really as big a deal as you make it to be (or a big deal at all).

        It’s a big deal to developers who were inconsiderate enough to do it in the first place. To do it in a non-breaking, non-confusing way requires slightly more care than doing it correctly to begin with. Hence why your $HOME is still a giant mess.

      • Neshura@bookwormstory.social
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        I mean if the code is well written it shouldn’t be hard in the first place. You likely have a sinlge code var for the config path already so instead of hardcoding it to be in $HOME make it check if the file is in XDG_Config, if not check if it’s in $HOME. If the file is in neither of these it does not exist -> create a new one in XDG_Config. If it does exist in $HOME -> Move it to XDG_Config.

    • gerdesj@lemmy.ml
      link
      fedilink
      English
      arrow-up
      10
      ·
      1 year ago

      They will if enough people whine about it.

      In the old days (I’m 50+) tumbleweed drifted through ~/ apart from my drivel and I’d have a folder for that so /home/gerdesj/docs was the root of my stuff. I also had ~/tmp/ for not important stuff. I don’t have too much imagination and ~/ was pretty clean. I was aware of dot files and there were a shit load of them but I didn’t see them unless I wanted to.

      This really isn’t the most important issue ever but it would be nice if apps dumped their shit in a consistently logical way. XDG is the standard.

    • Imnebuddy@lemmy.ml
      link
      fedilink
      English
      arrow-up
      8
      ·
      edit-2
      1 year ago

      I know developers are busy, and I don’t mean to berate them for their choices or work. I only have a two year Computer Information Systems degree and haven’t programmed a lot for a while, but supporting the XDG specification and remaining backwards compatible doesn’t seem to be very difficult or would cause so much breakage (of course, the amount of work would depend on the software and how the hardcoded path is implemented). I look up git repository issues for the software and tend to find ubiquitous examples like vim to be resistant to such change: https://github.com/vim/vim/issues/2034

      This is really frustrating and leads me to find alternative software, such as neovim/doom emacs instead of vim, nushell instead of bash, etc., just to be able to clear up my home directory. I don’t mind if I have to wait for XDG to be supported, but many important projects just label the issue as “won’t fix”. I totally understand where you are coming from.

      List of software with hardcoded paths at this time: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded

      • Kogasa@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        If you install config files to the new location and prefer the new config file location over the old, you risk accidental misconfiguration when a system has both config files (e.g. in a build pipeline that installs the software and then copies the config to the old location). It is not impossible to solve, but there are questions that require some care if you have a large userbase and solidified codebase. More care than it takes to do it right the first time.