myst icon indicating copy to clipboard operation
myst copied to clipboard

Use `MYST_HOME` environment variable for configuring load dirs.

Open faultyserver opened this issue 7 years ago • 3 comments

The old MYST_PATH that allowed multiple paths similar to $PATH has been removed in favor of MYST_HOME, which should always point to the install location of the currently-active version of Myst. This is both simpler in terms of the implementation, and more intuitive to reason about

This should correspond with changes coming in mtenv that will set MYST_HOME in the shim before running myst.

For now, users who do not use mtenv will have to set this manually, though we can probably check and ensure it is set as part of the VM setup. I think this should probably emit a warning and notify the user what the VM will use in its place, since it might not always be accurate (e.g., if a user wrongly installed myst directly into /usr/local/bin without moving the standard library as well).

Perhaps a better solution would be to disallow execution if MYST_HOME is not set?

faultyserver avatar May 28 '18 20:05 faultyserver

One other thing to consider with this is that running scripts without a login shell would probably end up not setting MYST_HOME for a lot of users, at least ones who aren't using mtenv.

With mtenv, /usr/local/bin/myst is a shim that automatically sets MYST_HOME, rather than relying on the shell profile or something else to set it, so this isn't an issue.

On manual installs, even if a user sets MYST_HOME in something like ~/.bash_profile, it won't be loaded for non-login shells. Realistically, this probably won't ever be an issue, and it can be solved by editing /etc/profile or ~/.bashrc or whatever with the variable as well. The only case I can really think of is background processes/daemons, and we can always come back to address this later.

faultyserver avatar May 29 '18 14:05 faultyserver

A myst daemon sounds like a terrible idea IMO. It'd be more like a myst demon :stuck_out_tongue:

As the primary goal of myst is to support users as best as possible, I think a strong competitor for how to set MYST_HOME in manual installations is the Makefile – I mean, the purpose of Makefiles is very much to aid installations.

A manual installation should be done with the Makefile, any kind of other manual installation would be little, but meaningless. This is how I imagine a manual installation:

  • make install MYST_HOME=/opt/myst/%v (or wherever you want it – and of course with a default value)

Where %v gets substituted with version just because its nice. This install a myst executable to /opt/myst/<version>/bin/myst, the stdlib to /opt/myst/<version>/stdlib, and installs a shell script /usr/local/bin/myst (unless otherwise specified) that sets env MYST_HOME to what specified in the Makefile installation, and executes myst.

If not: every OS should have some way for environment variables to be set (even when not running login shells) – so worst case scenario is to force manual setting.

EDIT: Although for embedded Myst, this would not be sufficient though.

Jens0512 avatar Jun 08 '18 12:06 Jens0512

That sounds like a pretty solid plan to me. I certainly think it's fair to say "if you don't use mtenv or make install, it's your responsibility to set MYST_HOME before running Myst".

faultyserver avatar Jun 08 '18 12:06 faultyserver