normalize install dir structure

[Gankra]

Because we initially regarded the CARGO_HOME structure as "overkill" the ~/some/path and $MY_ENV_VAR/some/path installdir strategies do not make a separate bin/ subfolder, which limits the scalability of the approach somewhat, and adds a ton of special case paths to installers/updaters.

Also the MSI installer really does its own thing altogether when installing to ProgramFiles.

We should change everything to be shaped like CARGO_HOME, with ./bin/ and ./env (on unix), with room to expand to having libs dirs as well.

This will require migrating existing users of ~/some/path, but will be good longterm.

[mistydemeo]

On Unix in particular, we should adopt the FHS layout. This lines up with the layouts used by both Linux and macOS. The paths we install to should be, essentially, mini FHS layouts with bin for binaries, lib for libraries, and we can consider things like share for config, etc.

We use a version of this today in the Homebrew installer config.

[ashleygwilliams]

so there was a long discussion in our internal channel about the merits of this normalization, which i will do my best to summarize here for a future design conversation in the near future.

• @ashleygwilliams shared a concern about how global this change would be and how it may potentially cause breakage for existing users. this led to a conversation with @mistydemeo about the motivation for the change.
• @mistydemeo explained that one motivation for the change is that it adds structure to the dir, which previously had nothing. one part of that structure is also the potential to better support applications that ship with non binary assets such as dlls, which @ashleygwilliams mentioned had been a recent user feature request.
• @ashleygwilliams then brought up the concern that "splatting" the apps of multiple files across a "shared" file organization structure could cause name collision issues and making uninstalling more complex.
• @mistydemeo brought up that many language (C and C++ were mentioned but more were implied) and os ecosystems expect this particular style of hierarchy
• @ashleygwilliams shared that she accepts that it is useful for some users but isn't sure that we should impose that as a default for all users
• @Gankra shared that she doesn't care about the expectations or standard FHS structure but would still like to see this pattern rolled out to all users because it makes cargo-dist features more compatible and consistent
• @ashleygwilliams suggested that we could "lead with config" for this and make a bin dir config key that defaults to . (current behavior) but can be set to "bin" to achieve the new behavior, and we can see how that plays out with users
• @mistydemeo thought that seemed reasonable and suggested making a table for assigning destinations for different things (i think filetypes was implied but not stated directly)
• @Gankra mentioned that bin suffixing (an alias for this proposed feature) could work in our current install directory feature, but it would potentially make it harder to maintain. she elaborated that the updater and the installer need to communicate about the bin suffix being appended and implied that that was already pretty complex
• @ashleygwilliams suggested that making the bin dir explicit in config may help alleviate that, but further discussion was then postponed until a future time.

---

personally speaking i think what i've realized typing this out is that if we go with this heirarchical structure, we are assuming that the dir a user is providing is not shared by multiple apps (likely using a different install/release process, and/or outside the repo). this comes down to the question- should an install dir and an app be 1:1. currently we take no stand on this, but i do think adding more structure means that we need to have a stronger opinion on this and/or let folks choose/opt-in to structures.

i started drawing this out in miro but typing file systems sucks so i didn't finish but hopefully this gestures at the issue. drawing this- another solution here is to have users make their install dir namespaced if they know they are publishing multiple apps there.