modularml / mojo

The Mojo Programming Language
https://docs.modular.com/mojo
Other
22.05k stars 2.54k forks source link

[Modular CLI]: Please follow the XDG base directory standard on Linux #1156

Open gdonval opened 8 months ago

gdonval commented 8 months ago

Issue description

At the moment modular writes things in $HOME/.modular on Linux and does not follow the XDG basedir specs.

The problem is that it does not play well at all with Linux, preventing standard collective relocation of state through setting environment variables. $HOME/.modular is an arbitrary choice, XDG is a standard providing many advantages detailing how to do it properly.

Please add this to your roadmap.

Steps to reproduce

Version Info

- v0.2.1
- Ubuntu 22.04
rivy commented 8 months ago

Please follow the XDG standard on all platforms (not just Linux).

lattner commented 8 months ago

@zbowling fyi

zbowling commented 8 months ago

Duplicate of https://github.com/modularml/mojo/issues/739

We will likely follow XDG standard at some point (only about half the Linux ecosystem of packages really does today), but we have to implement a way to migrate existing installs when we do. Some of our dependencies (eg parts of LLVM) also don't respect XDG and upstream still hasn't made it priority with some downstream distros maintaining their own patches. When we officially support more linux distros other than Debian based distros (most of which are still slowly migrating official packages to XDG specs currently) to support distros that are further down the path of full XDG spec adoption (like Arch linux), we will likely make it default.

There is a work around for now. You can set the MODULAR_HOME env to your XDG_STATE_HOME path, re-auth, and install there.

export MODULAR_HOME="$XDG_STATE_HOME/modular"
modular auth ...
modular install ...
gdonval commented 8 months ago

only about half the Linux ecosystem of packages really does today

This is not a good excuse. Each one of them is a pain to work with, let's not make modular an extra one.


There is a work around for now...

Not it is not. The standard mandates that $XDG_STATE_HOME (and co.) should inform the program about where to put things. A way to move things for this specific application is not what has been asked for.


We will likely follow XDG standard at some point

Please add it to your roadmap so that it is not forgotten.

zbowling commented 8 months ago

Unfortunately it's the only solution I can share today. It's a workaround that is similar to workarounds one can employ for a lot of packages that don't respect Free Desktop's XDG base dir and user dir specs today: https://wiki.archlinux.org/title/XDG_Base_Directory#Partial

Right now, given this primarily affects Arch linux users where the home directory is by default not writable and that Arch is not officially supported right now for us (only Ubuntu and Debian at the moment), and given there is a workaround for users on unsupported platforms, we likely won't prioritize full support of XDG until we later expand our Linux distro support given the engineering time to get there.

Freedesktop XDG base dir and user dir spec supporters have been fighting a bit of a 13 year long uphill battle to gain widespread adoption in the Linux ecosystem and Arch linux making it inconvenient to run software that doesn't implement it has been the only recent forcing function to gain more adoption of the spec in recent years. Right now there a lot dependencies, especially common ones in the compiler world, that still don't support it. Including a lot of LLVM based compiler tools and many other compiler suites (like Rust and Go).

We hear you though and will get there. I can't give a timeline yet though.