Hi everyone I’m a long-term user of experimental.hidden-snap-folder=true (for ~/.snap) since 22.04, and I’ve found it perfectly stable through multiple dist-upgrades.
Given its stability, I’m interested in contributing to snapd to help make this the default, hopefully before the 26.04 LTS. This would be a great fix for a well-known desktop papercut. I’m especially curious about the status of a migration path for existing users (~/snap to ~/.snap) and would be happy to help.
I tried asking about this in the snapd matrix but didn’t hear back but asked in snapcraft matrix where I was told to reach out here. What would be the best way to get involved and help move this forward for the upcoming LTS? I am interested in helping shape Ubuntu releases
This work I way larger than a papercut and will need support from snapd devs. I have moved your message to a separate topic to keep the discussion separate.
I brought this up internally. Bit of a sad news but I don’t think there’s any interest left to pick this up anytime soon. Even in the form of mentoring a community contribution.
The previous approach, similar to the original proposal, was met with a very negative feedback from the community. While everyone’s is entitled to their opinion, and actions speak louder than words, it’s sad nobody stepped up to do the work of even designing a better solution that would be within the constraints of what is possible and keeping some backward compatibility. Folks from the team who worked on it before are not exactly happy at the though of looking into it again either. Given all this, this topic has been put on ice for the time being. I would not expect to see any changes in that area within the next 6 months.
While, I think, you’re welcome to try it, write a proposal, open a PR, I’m afraid getting some interest from the reviewers will be hard.
Thank you for bringing this up with the team! While it’s unfortunate this has been put on ice for now, based on the discussion post and launchpad bug, it seems that the design choice of migrating ~/snap to ~/.snap/data was welcomed by the community and there was major backlash only to ~/Snap migration. From my understanding it is a conflict between the design choices below:
The Consumer Facing Preference: The desktop should be transparent and manageable for all users. A user’s application data is their data and should be visible and accessible (like ~/Documents), not hidden in a complex structure. Kind of what Apple does on macOS with ~/Library.
The Community Preference: The home directory should be “clean” and free of clutter. Application data belongs in standardized, hidden XDG directories (~/.config, ~/.local/share, ~/.var), and users who need this data are technical enough to find it. This is what flatpaks do and store data in ~/.local/share/flatpak/.
Now, I’m interested in the Canonical devs perspective on the following:
Why wasn’t migrating to ~/.snap/data chosen after seeing support for it from the users?
This aligns with the community choice instead of ~/Snap, is similar to how Flatpaks handle user facing data, and keeps the home directory neat. For example, A consumer first gaming OS like SteamOS is using flatpaks for app support which again stores user facing data in a hidden directory so isn’t something we should rule out completely from a preference stand point because it also seems like the majority users are more accepting of a solution like this.
If the primary goal is discoverability, why not use ~/Applications or ~/Applications/Snap?
Users are already adopting ~/Applications for their AppImages. Leveraging this existing behavior would create a single, understandable “Hey, all the apps are here!” location. This seems like a practical, one-stop solution as well that aligns with the Ubuntu Core desktop goal, providing users a default directory to store and access their Snap data (and AppImages as a nice addition).
This was also a suggested on launchpad sometime back #365
I would be very grateful if you could share my questions with the snapd team as well. I value your and the snapd teams’ opinions so hearing back on these questions would help me frame a better proposal.
