Move swiftly default home directory to ~/.swiftly for all platforms

[cmcgee1024]

Standardize on a single location where swiftly is located on both Linux and macOS.

[cmcgee1024]

@swift-ci test macOS

[compnerd]

If swiftly wants to support Windows at any point - this wouldn't work. We should be using %LocalAppData%\Programs\swiftly\ for this content there.

[patrickfreed]

For Linux, I'd also pretty strongly advocate against making this change, as it would mean swiftly no longer conforms to the XDG Base Directory specification, which is somewhat of a standard on Linux for these kinds of things.

[cmcgee1024]

Thanks @compnerd I think that Windows is certainly going to be a bit different with respect to swiftly flows. That does sounds like a good place to install swiftly on that platform.

[cmcgee1024]

@patrickfreed thank you. The precedent I'm going for here is SwiftPM. It installs a ~/.swiftpm directory for its local data. There's other precedents outside of Swift too, like ssh. Perhaps the XDG is more relevant to graphical desktop applications on Linux? I notice that none of the usual shells have any XDG directories on the default PATH, for instance.

Having a smaller more concise path will make it much cleaner in people's PATH.

There is still code in Swiftly that uses XDG_HOME on Linux as the default base for the .swiftpm directory, so if it's set to something different on that platform it will place the files in there.

[compnerd]

XDG is more comprehensive. Many of the other Linux packages have started adopting XDG recommendations for configuration. IIRC, fish is a prime example of a non-UI application adhering to the XDG specification. In general, that is considered good behaviour for applications to adopt that as a successor to FHS.

[rauhul]

I also vastly prefer swiftly using Application Support on darwin platforms, the million ~/.foo directories are deeply annoying

[xtremekforever]

Honestly I like the ~/.swiftly directory better. It makes it easier to uninstall by just doing rm -rf ~/.swiftly

[Frizlab]

The XDG specifications are supported by various tools, including command line tools, including but not limited to git, curl, ccache and cups.

Some tools, like git, support having configuration files in ~/.git if the XDG location is empty/does not exist, probably for backward compatibility.

On macOS I usually prefer the normal macOS location be used if possible, but XDG would be fine too (in particular one could change the XDG_* variables to point to ~/Library/… if they wanted to use those particular location for their configuration files).

I try to push XDG where possible and even wrote an implementation of the specifications in Swift, as I am strongly against the multiple dot-files that hang around in the home directory (most of the time w/o proper permissions BTW).

[cmcgee1024]

Cargo appears to have picked ~/.cargo on my Debian desktop box with the full Gnome GUI, and on macOS too. Same with git, and ssh, and nvm. I'm just not so sure that the XDG layout is really taking hold. Go is installing default binaries in ~/go/bin on both Linux and macOS for me, which appears to be well outside the XDG. Any other tools in the swiftlang realm using XDG, or any plans to switch them all over? That might be a good time to update swiftly too.

I think what's interesting is that despite the XDG, the most common shells in Linux distros (bash, zsh) aren't adding any of the XDG locations to the default PATH, which could accelerate adoption, I suspect.

[Frizlab]

• git fully supports XDG but defaults to ~/.git for backwards compatibility;
• cargo talked about supporting XDG, but the main issue seems to be backward compatibility;
• go and nvm have a way of changing their home but do not seem to have an interest in being compliant with XDG out of the box;
• ssh won’t support XDG.

AFAICT, the issue to support XDG is usually backward compatibility, which is why I think doing the support for it now (before 1.0) would make the more sense.

[cmcgee1024]

Backward compatibility can be really tough, so it doesn't surprise me that these tools don't necessarily default to XDG standards, but instead have opt-ins.

Is there any sign of macOS/Windows adopting XDG / freedesktop.org, or is this still mostly just Linux/BSD world?

Another concern here is consistency within the Swift ecosystem. That's why I was wondering if there are existing Swift projects, preferably ones in the swiftlang organization, that have adopted already. It would be really strange for swiftly to support XDG layouts, and not SwiftPM, for example. The user experience could be confusing and frustrating.

Perhaps we can consider enabling XDG across all of swiftlang as a joint activity in some future release.

[compnerd]

No, Windows doesn't support XDG and is unlikely to do so I imagine.

[patrickfreed]

Also of note, vim just added support for the spec as well: vim/vim#14182

Perhaps we can consider enabling XDG across all of swiftlang as a joint activity in some future release.

I think if we tie it to something like this, it's very unlikely the switch will happen even in the medium term future. Prior to 1.0 is the best time to make these kinds of choices, especially in this case because swiftly already conforms to the XDG spec (and a decent bit of effort / thought went into that conformance I might add).

It would be really strange for swiftly to support XDG layouts, and not SwiftPM, for example. The user experience could be confusing and frustrating.

They're different projects, so I don't think it's necessarily a huge surprise that they might have different configuration mechanisms, especially given that the target audience in question for the XDG spec conformance are Linux Swift developers, who are used to dealing with this kind of thing. If anything, I think this argument would be better directed towards getting SwiftPM to adopt the standard, rather than having swiftly drop its adoption of it.

I notice that none of the usual shells have any XDG directories on the default PATH, for instance.

On Ubuntu at least, ~/.local/bin is included in PATH in the default .profile (/etc/skel/.profile):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

Lastly, if something like ~/.swiftly is preferred for a given user, that can easily be configured during installation without dropping conformance with the spec by default.

[cmcgee1024]

On Ubuntu at least, ~/.local/bin is included in PATH in the default .profile (/etc/skel/.profile):

Because of the potential for collisions with tools like clang, clang++, and others that are in the toolchain, and also to give ability for users to more easily swap out the path for swiftly to switch swiftly off, swiftly and the proxies were moved to ~/.local/share/swiftly/bin. I couldn't find anything in XDG for binaries scoped only to a particular application so we use the XDG_DATA_HOME for this. This is a fair bit longer path than just ~/.swiftly/bin. Also, the equivalent for macOS is longer, has spaces, and it's inconsistent across platforms: ~/Library/Application Support/swiftly/bin. These two are not likely to be on a shell's default path, likely because XDG doesn't appear to address this particular concern.

The hope is to simplify, shorten these paths, and make them consistent across Unixes.

I checked my Ubuntu 24.04 desktop and I see that cargo is doing the identical thing despite it being in a full XDG environment. Cargo installs its files in my ~/.cargo directory. I think that Rust is commonly used with Linux since it's in the kernel itself, but yet it doesn't follow the XDG standard for me here. It is also establishing its own kind of standard for toolchain managers, since nvm does the same thing in ~/.nvm. The paths are very short and simple, probably to make it easy to opt in to a specific toolchain on the fly by modifying the path. I think it will be good to have that for swiftly as the default user experience.

I think if we tie it to something like this, it's very unlikely the switch will happen even in the medium term future. Prior to 1.0 is the best time to make these kinds of choices

Something as long and established history as vim can make the choice to fix this just last year. The Swift ecosystem can do it too.

[patrickfreed]

The hope is to simplify, shorten these paths, and make them consistent across Unixes.

In my opinion, I don't see shortening the length of the path that contains the binaries as a worthwhile tradeoff for breaking from the XDG spec, especially given that swiftly will update the users PATH for them and the reduction is only 10 characters or so. I also don't think consistency across Unixes is a necessarily a desirable goal, given they have different standards and expectations. I don't really have strong opinons if we decide to move the macOS one to ~/.swiftly as I'm less familiar with the standards there, and the path swiftly is using there is indeed quite a bit of a headache.

I checked my Ubuntu 24.04 desktop and I see that cargo is doing the identical thing despite it being in a full XDG environment.

It is true that cargo doesn't conform, but it was also a quite unfortunate choice for them, in my opinion at least (note the thumbs up vs thumbs down on the issue for adding XDG spec conformance to cargo). The link @Frizlab discusses the history there and the various attempts to improve it, which could be useful to check out when weighing things here. It's also true that other installers like nvm don't conform either, but again that doesn't mean we have to take that path too. I think it's preferable to conform to the standards of the given platform rather than the family of other similar open source tools that are doing the non-standard thing.

Something as long and established history as vim can make the choice to fix this just last year. The Swift ecosystem can do it too.

Notably, it took them 7 years to do so, whereas we have the opportunity to get it right on day 1.

[cmcgee1024]

Thanks everyone for the feedback on this topic. I'm closing this PR, but it's still here to record the discussion.