Is there a better way to manage getting the right user-console-bin-dir on PATH for running shells when upgrading Racket?

Questions & Answers
1

Context

Continuing the conversation from (fourteenth racketcon) about releases and managing Racket versions:

When I install a new Racket version, I do the following:

  • brew upgrade --cask racket (after brew update)

  • raco pkg migrate <old-version>

  • I then use tmux to send the following commands to all my open shells:

    pathrm ~/Library/Racket/<old>/bin
pathrm man ~/Library/Racket/<old>/man
pathadd ~/Library/Racket/<new>/bin
pathadd man ~/Library/Racket/<new>/man

    It is not uncommon for me to have ~20 open shells for ~10 different projects (not all Racket) in a tmux server.

(Here's a tmux key-binding for sending a command to all panes, and here are my shell definitions of pathadd and pathrm for Zsh. I have similar commands for Bash in that repo, though they're kludgier and I won't link them.)

These paths come from setupdirs with find-user-console-bin-dir and find-user-man-dir so that I have them on PATH, for example to have launchers available from user-scope installed packages.

The tmux part of this process requires making sure none of my tmux panes have a program running that isn't the shell, and can still break when a shell is in Normal mode (I use bindkey -v in Zsh similar to set -o vi in Bash). New shells automatically get the right paths.

I've looked at /etc/paths.d, but I think that only works for new shells, and I already have a solution for that.

Question

Is there a better way for me to manage these path updates for user directories?

Having a single place to point to ("current") would be nice and would probably fit with the "build racketup on top of raco cross." In the meantime, what do others do? Is there a workflow option I'm missing?

2

For testing Racket Mode against various versions of Racket that I have installed simultaneously, I'm mostly resigned to using explicit full ~/racket/VERSION/bin/racket pathnames.

  • I use the Racket install.sh on Linux.
  • I don't use the "unix install" option; instead I install each version to its own own directory.
  • In a Makefile I'll have a RACKET var, so I can RACKET=path/to/racket make.

I also build Racket from source (from time to time) and I tend to set PATH to be that, as my default for casual shell use. But mostly I'm "indirectly" running Racket from a Makefile or from Emacs, and the full pathname isn't a PITA.

For your scenario, instead of trying to update PATH vars in dozens of live shells, might it be less-worse to define some symbolic links for a half dozen things like racket, raco, drracket? Then you can just update those symlinks, and all the shells will just follow them?

Even if that works: I'm not sure how to deal with man (I rarely use that) but IIUC the man env var is just an override for the primary manpath command? So something hand-wavingly similar to the symlink approach could work for that??

1 Like
3

I use this set of shell scripts to manage switching between versions of Racket: GitHub - takikawa/racket-dev-goodies: Scripts for Racket developers

1 Like
4

Thanks to Greg's symlink idea, here's what I have now: symlinks ~/.racket-bin and ~/.racket-man that point to the appropriate directories.

Note that these are not for racket binaries and documentation, but for user-scope packages's binaries and documentation. For example, Frosthaven Manager has a racket-launcher configured, so installing the package gets you a command-line frosthaven-manager that can run the program: that's the bin directory I want on PATH, and it changes with each version.