Fork me on GitHub
#portal
<
2023-11-14
>
selahb15:11:38

I have a bunch of portal code that I want to use across projects as a dev dependency (format-specifying taps, routing between portal instances, etc.). Is there a preferable way to do this? I was thinking creating a project and using it as a local dep, but I think that would require some overhead anytime I wanted to edit that code while working in another project. Lighter weight would be a symlink to a git ignored file in the "dev" dir, which would require one-time overhead when creating a new project. Git submodule, perhaps? Anyone else found a better solution?

selahb15:11:24

I realize this might be a Clojure question, not a Portal question, but I'm guessing it's a fairly common consideration for Portal users.

practicalli-johnny16:11:44

Once my portal code was stable, I created project templates that would add it to new projects. The code is kept in the Dev directory and included on the path aica a Clojure CLI alias https://practical.li/clojure/clojure-cli/projects/templates/practicalli/ To add code to existing projects I would use a similar Clojure CLI alias with a local/root to include the Portal code from a local project. This approach would also be useful if the portal code was still evolving. If the Portal code was quite stable and unchanging, then I would use a git coord for the dependence, after sharing the portal code in a suitable project.

lukasz16:11:47

I use local dependencies plus a global dev profile in deps.edn - as long as that profile is used I have access to my portal extensions/helpers

👍 2
seancorfield16:11:22

Most of my Portal code is in Calva custom REPL snippets so it's available to all projects (and in my VS Code/Calva setup repo on GitHub).

selahb21:11:49

@U04V70XH6 Interesting! But I use Emacs (mostly), so while it that would be possible (what isn't in Emacs?), I think it would be awkward to put Clojure in my Elisp. Are you using cljc code and Joyride?

selahb21:11:19

@U05254DQM Ah, yes, I think that sounds like about what I was looking for, if I'm understanding. Using local:root to point to a non-project dir in an alias in the global Clojure config.

selahb21:11:33

Then you just start the repl with that alias when you want the Portal code. Curious if you can then hop over to that dir and start editing code while connected to the project repl and it would "just work." Guess there's one way to find out!

seancorfield22:11:19

Portal and Joyride are a big part of why I switched to VS Code (from Emacs, with a couple of detours).

practicalli-johnny22:11:24

@U066ZAMBJ changes made to the code made in a project included via a :local/root would need to be evaluated in the REPL, but the repl itself shouldn't need to be restarted (as the project is already on the class path)

selahb16:11:24

@U05254DQM Works as advertised, thanks!

👍 1
selahb17:11:12

@U04V70XH6 I love the idea of Joyride, but my Emacs muscle memory runs deep (not just the keybindings, but the idioms), so I have a hard time getting into VS Code. It's my secondary work environment and my first choice for Python dev, though, so I'll keep trying to dig deeper! Incidentally, I borrowed liberally from Joyride's code base to get my Obsidian.md REPL running.

1
Braden Shepherdson18:11:27

I'm building a custom viewer for a parse tree, as a debugging aid for writing grammars. navigating the tree using clojure.zip would be handy, but I can't require clojure.zip in Portal CLJS. since that's a standard CLJS library, I am puzzled.

djblue18:11:18

The cljs runtime in Portal is using sci which requires manual specification of which namespaces to include. https://github.com/djblue/portal/blob/master/src/portal/ui/sci/libs.cljs#L58 are those namespaces. It should be relatively easy to add more namespaces.

djblue18:11:25

Did you want to try making the changes locally to see if they solve the issue?

Braden Shepherdson18:11:22

I can give it a try, sure.

👍 1
Braden Shepherdson20:11:23

hm. perhaps I did it wrong? I added it like this

(def namespaces
  (merge
   (sci-import/import-ns
    clojure.zip
    goog.crypt.base64
    #_...
and tweaked my deps.edn to use :local/root. but I still can't p/eval-str my viewer ns.

Braden Shepherdson20:11:16

`clojure.zip` doesn't have any requires, so I suppose I could send that namespace to the running portal env and it would start working? but it has JVM-isms in it like Exception

Braden Shepherdson20:11:26

I'm moving again by pasting clojure.zip's code into a CLJS namespace in my classpath and requiring that instead.

Alan Birchenough23:11:25

I’ve got a bit of a brain-teaser here. I am tapping a var that contains a lazy sequence of vectors. It gets displayed like this:

djblue02:11:57

Ohh, this is likely due to the data matching the spec for stack traces. https://github.com/djblue/portal/blob/master/src/portal/ui/app.cljs#L451-L452. For now, you can add some metadata to use the inspector by default, (with-meta [...] {:portal.viewer/default :portal.viewer/inspector}) . I should update portal to always use the inspector by default and only opt-in to other viewers.

Alan Birchenough02:11:50

Great. Thanks for the tip. I'll give it a try tomorrow.

👍 1
djblue02:11:16

My thinking was that it would be a good way to discover new viewers. If data matched a spec, use that viewer instead of the inspector. However, I feel like it's not worth it given that it can cause confusion at times.

Alan Birchenough02:11:18

Right. An elegant idea that unfortunately leads to brittleness in some scenarios.

Alan Birchenough02:11:51

Excellent. Many thanks. 😄

Alan Birchenough23:11:37

Otherwise, there are no error messages anywhere.

Alan Birchenough23:11:42

The REPL quite happily prints it like this:

Alan Birchenough23:11:17

I can’t seem to find out what is so exotic about this value that the portal does not want to render it.