Sesman - next

[vemv]

Context

Sesman-related functionality has some acknowledged complexities, nuisances and limitations.

We're considering inlining this library (which is generic) and evolving it freely to fit CIDER needs more tightly.

A total rewrite is not out of the equation, although it wouldn't be wise not to give forking a good try.

Proposal

Discuss beforehand what do we want from a connection manager. Ideally we could come up with a spec that can be translated to a set of unit tests, that can be clearly understood as documentation of the intended behavior.

Design constraints

A good solution should support the following features/scenarios:

• Keeping track of connection objects, as created by CIDER
  • CRUD functionality
  • Keeping track of the state of each connection (active, processing, dead, etc)
    • This tracking helps finding the best possible connection satisfying a query
      • e.g. if there are two valid choices and one is busy, pick the free one
• Mapping a file (or a buffer, more broadly) to an existing connection object.
• Perform well for most operations
  • This is because (cider-current-repl) can be invoked in unsuspected places powering all sorts of interactive widgets / functionality.
• Provide the ability to work on multiple projects at once
  • Each having its own clj/cljs repls, or a sensible fallback.
• Support monorepos
  • This probably means being careful around the notion of a root directory.
• Be "dwim"
  • Probably CIDER lost a good deal of dwim-ness when Sesman was introduced.
  • i.e. one can get overly strict behavior which can result in the wrong (or no) connection being used.
• Foster immutable connections
  • This one is sujective, but I'd like the manager to treat each connection as immutable (e.g. it cannot suddenly change from cljs to clj)
  • Treating things as immutable allows to cache things better
  • n.b., with current tech like Piggieback and shadow-cljs, a cljs repl can change from cljs to clj, but that clj state should be a temporary, irrelevant one
    • maybe in a close future, we can have middleware making :cljs/quit a no-op, so a cljs repl would always be a cljs repl.
• Support an open set of platforms
  • e.g. bb, clr
• Support reusing REPLs
  • I'd think carefully about this one (it goes against immutability), but keeping repl history and supporting REPL restart over the same port seem desirable
    • Particularly when JVM restarts can be a routine op.
• Have tooling awareness
  • CIDER, namely its set of middleware, is always implemented over JVM clojure. So it never makes sense to pick a cljs/bb/clr connection for tooling purposes.
• (Maybe) support multiple REPLs for the same type and project
  • It doesn't seem crucial to me, but it's a reasonable thing to want as a user, e.g. I want two REPLs each with its own history, for exploring two aspects/features/namespaces of an app independently
  • The bad part being, it may make things more complex
    • e.g. there are two valid conns, which to pick?
• Support configuration
  • People may want diferent degrees of strictness - probably we shouldn't enforce a single approach.

[bbatsov]

I wondering if we should consider all the problems that people face with sesman or should focus only the most common ones - e.g. the lack of way to set an active session manually (and suppress the session inference) or the lack of a way to set a "fallback" session if none of the current sessions matches the inference logic (this was causing issues when browsing source code before the introduction of "friendly" sessions). The performance aspect of cider-current-repl is also quite important IMO, given how frequently its needed.

I'm just concerned that a full redesign might turn out to be a very long process - sesman itself took forever to develop. So, I'd rather start small and take out the big guns only if there's a strong justification to do so.

A list of known sesman-related issues can be found here.

[vemv]

I think we can decouple a "spec" of the full envisioned/necessary behavior, and an actual tactical plan. The former can be a rough guide, leading one to better decision making.

Perhaps we can do both things? Refined the spec per my OP, and then prioritize the direction you hint here.

[bbatsov]

That'd be fine by me.

[vemv]

Nice! Did you get to eye my spec in detail? Would appreciate any observation.