d@nny disc@ mc² (@[email protected])

learning about cargo-dist and this project (https://toot.cat/@Gankra/111807326627428474) makes me feel extremely conflicted for several reasons. in particular the necessity of staged releases (a major necessary feature of the QTed project) is because cargo-dist doesn't have any way to redirect download URLs once an ["installer"](https://opensource.axo.dev/cargo-dist/book/installers/index.html) is created, and (unless i misunderstand) there's no caching of downloads except perhaps by hand in the installer script, which only has release artifact-level cache granularity because it doesn't seem to encode artifact provenance in a structured way. the pants project has been working on a staged installer format called scie which is highly configurable (see [ptex](https://github.com/a-scie/ptex) for how it can be extended to achieve URL redirection and granular caching), and i think an investment in a standard protocol for installers seems like the right way to avoid doing a lot of extra infrastructural work including the entirety of this particular github repo. this makes me conflicted because "automating" a complex process can be used as a tool of vendor lock-in especially when it's not paired with a concerted effort to standardize and formalize the intermediate steps. when i shipped what i consider to be the first iteration of ptex (see [ipex](https://github.com/pantsbuild/pants/pull/8793)), i then spent the next three years upstreaming the necessary functionality in pip to optimize the process, including the implementation of the [PEP 658](https://peps.python.org/pep-0658/) artifact metadata format. i gave a whole [conference talk](https://cfp.packaging-con.org/2023/talk/HPUHU7/) on this process ([video](https://youtube.com/watch?v=DTKSnU2EqBY), in which i specifically and respectfully call out cargo for not having a package metadata standard like PEP 658) and i'm going to write up a blog post soon on how to develop standards to avoid having to solve hard problems. to summarize: developing the installer format for cargo-dist into some sort of standard which explicitly supports staged releases instead of requiring users of cargo-dist to also use this backend service in order to achieve staged releases seems like a good way to minimize repeated effort, if the goal is to minimize repeated effort.