PkgTemplates.jl icon indicating copy to clipboard operation
PkgTemplates.jl copied to clipboard

Published 20 hours ago • verified publisher icon JuliaCI

New REPL mode for package developers

Open rapus95 opened this issue 4 years ago • 4 comments

Disclaimer: This probably should go into a new common (but abstract) package as it shall only provide the API/abstract hooks needed for having a unified interface. @christopher-dG @davidanthoff @oxinabox I just realized that this is the refinement of everything I was asking in the last few weeks, here and in PkgDev.jl and in Pkg.jl Especially:

  • Common interface (https://github.com/invenia/PkgTemplates.jl/issues/144, https://github.com/JuliaLang/PkgDev.jl/issues/168)
  • REPL mode integration (https://github.com/JuliaLang/Pkg.jl/issues/1762, https://github.com/invenia/PkgTemplates.jl/issues/135)
  • stateful developer context and updating (https://github.com/invenia/PkgTemplates.jl/issues/136)
  • and probably a few more

Creating a new REPL mode is certainly the better place than Pkg.jl REPL mode since the latter is more focused on package users rather than developers. We'd also be restricted to only a single command if we stayed there. On the other hand, an explicit developer mode would allow arbitrary commands to be defined in the API and we'd have the freedom to not have to be fool proof as it's explicitly targeted at developers to provide a convenience/utility shell. When defining such a new dev REPL mode API it'd be easy for different packages to hook into certain functions to provide their specific functionality. By that we'd be able to unify multiple developer packages which aim at different situations (like PkgTemplates.jl and PkgDev.jl) and even allow developers to plug in their own ideas. All while keeping each package independent of each other. In some sense the maximum orthogonality between functionality(REPL API) and approach(each individual package).

What are your concerns about that idea?

rapus95 avatar Apr 20 '20 13:04 rapus95

It seems like something that can exist as a separate package. Why not have a go at a POC?

christopher-dG avatar Apr 21 '20 02:04 christopher-dG

It seems like something that can exist as a separate package. Why not have a go at a POC?

That's what I meant with the disclaimer 😄 What's a POC? EDIT: Found it, I'll see how easy it is to come up with a proof of concept as I've never designed an API before 🙈

rapus95 avatar Apr 21 '20 13:04 rapus95

The point of a POC is that it doesn't need to be too polished so don't sweat it! 🙂

christopher-dG avatar Apr 21 '20 13:04 christopher-dG

Well, that's a veeery basic and probably sort of bug prone POC (with only "deps ARGS..." redirecting into pkg"ARGS..." working for now) https://github.com/rapus95/Developer.jl

rapus95 avatar Apr 21 '20 16:04 rapus95