Split off module browser from `drracket-tool-lib` to a new `drracket-tool-lib-gui` package?

[greghendershott]

I've been looking at packages that depend on gui-lib when maybe they need/ought not to.

One is drracket-tool-lib. However "most" of it doesn't use racket/gui/base. I think the only portions that do are two modules:

• https://github.com/racket/drracket/blob/master/drracket-tool-lib/drracket/module-browser.rkt
• https://github.com/racket/drracket/blob/master/drracket-tool-lib/drracket/private/standalone-module-browser.rkt

Would it be possible move those two files into their own package, called (say) drracket-tool-lib-gui, and adjust the drracket-tool meta package?

IIUC the files would move within this git repo, and get their own package info.rkt and node on pkgs.racket-lang.org --- but the collection paths would remain the same so they'd still end up installed in the same place and nothing would break. I think. Does that seem correct?

[rfindler]

I think we'd need to keep drracket-tool-lib as depending on gui (becuase it needs to provide the same set of libraries) but we can make a new one that doesn't depend and then drracket-tool-lib can depend on that new one and also reexport those things.

[greghendershott]

Ah. Good point about the old one. Great idea about a new one. Would drracket-tool-no-gui-lib be OK (if I were to take a stab at a PR to do this) or do you have a better suggestion?

[rfindler]

I don't know of any precedent on the "package that avoids a dependency on gui-lib" naming convention! :)

May I ask the goal? Is it just a general cleanliness thing or is there a more specific usecase you have in mind?

[mfelleisen]

The Typed Racket world has modules such as typed/racket/base/no-check typed/racket/no-check and probably more. Search then suggested plot/no-gui module and plot/typed/no-gui.

[greghendershott]

I have a WIP branch for Racket Mode where the Emacs front end can use multiple Racket back ends.

One use case would be you have two projects using different versions of Racket, and you want to juggle both.

Another use case is you're using Emacs TRAMP to edit files on a remote server. In this case, the Racket back end is actually running on that remote server.

---

When the remote server is headless (e.g. Linode or Digital Ocean or Amazon or whatever), you might do a minimal Racket install. But the moment you install some package that depends on gui-lib, you get all that, too. One drawback is that might be too "heavy". Another is that, now that racket/gui/base is available, anything that requires it gets into the "cannot instantiate Racket in a second process" territory... or even before that mred fails to initialize and you get error messages because a display isn't present. So now you need to xvfb-run racket to provide a dummy X server.

On a headless server of course you probably won't want to run graphical desktop apps. (Although I suppose you could, with remote X Severs, that's not the use case I have in mind.) But you might want to use things like plot. And you might carefully install plot-lib instead of plot-gui-lib

TL;DR I'd like the Racket Mode back end not to force an install of gui-lib, due to its need for drracket-tool-lib.

---

Now that I'm using plot as an example, I realize that plot-lib vs. plot-gui-lib might be a precedent.

(I probably should have thought of that example up front, but I'm still kind of marinading myself in this headless remote server use case.)

[greghendershott]

Oh and I posted that before GitHub refreshed to show me @mfelleisen 's plot example. :)

[rfindler]

Thanks, @greghendershott that makes sense. Running a remote racket in some minimal installation connected to your desktop's emacs sounds really cool!

And yeah, the file-level dependencies are (I think?) already correct and account for the dependences on racket/gui/base. But if not, I should totally fix that.

[greghendershott]

Actually I shouldn't have offered plot as an example:

1. plot-lib (w/o gui) vs. plot-gui-lib isn't really a naming precedent for drracket-tool-lib (with gui) vs. a drracket-tool-no-gui-lib.

2. plot-lib isn't even a good example of the use case. Although it doesn't depend directly on gui-lib, it does so transitively -- through typed-racket-more. Maybe that could/should be untangled, too?

   Meanwhile pict-lib is a simpler/better use case example.

---

And yeah, the file-level dependencies are (I think?) already correct and account for the dependences on racket/gui/base. But if not, I should totally fix that.

Those seem to be correct, yes!

Even so, the package dependency is still a problem that I'd like to fix. (I wasn't clear from your comment if you agree with that.)

[rfindler]

Even so, the package dependency is still a problem that I'd like to fix. (I wasn't clear from your comment if you agree with that.)

Oh sorry! I agree it is important to fix and given your use case, also urgent. Let's go with no-gui in the name somewhere as good enough since I've not been able to come up with a better name. :)

[greghendershott]

Oh I remembered one precedent: macro-debugger-lib vs. macro-debugger-text-lib. And for similar reasons.

So "text" instead of "no-gui".

[rfindler]

Sounds good!

[rfindler]

Thanks, @greghendershott