Okay, thanks for reporting this. I will have a look.

“reload just all already loaded code” or something.

I also could start the repl from the project I’m editing I guess :thinking_face:

I think same applies to mount, and more, as the namespaces themselves can be stateful.

sounds like a good reason to use component over integrant imo

c.t.n.r/refresh re-loads all code causing unwanted side-effects, regardless of what state management system you use.

but true, component is bit better here.

but, doesn't poly know the classpaths? Is there, or could there be a (in-project "dispatcher") repl helper that would create a new classloader with just all the project dependencies? or poly repl project:dispatcher. .

This is why I tell people to avoid reload/refresh workflows 🙂 Aw, c'mon, you knew I was going to pop in and say that!

afair component's repl additions also call ctnr/refresh so using component over integrant wouldn't be a solution by itself

Yeah I don’t use that refresh thing either. Not sure I understand why it would be necessary. I guess that’s a different discussion though lol

@U08BJGV6E I never use that .repl stuff for Component either 🙂

I don’t expect everyone to like that 🙂 but, many people lean on that and would be nice to get it working with polylith. One can narrow the reload directories with c.t.n using set-refresh-dirs. here’s the motivation for the refresh if @U03HTB6V19B if you have not bumped into it earlier: https://github.com/clojure/tools.namespace#reloading-code-motivation

but, a poly repl project:dispatcher command would be actually much better => “give me a repl for the project with just all the deps it requires.

there it would be safe to refresh everything.

It would be nice to educate people to adopt REPL-friendly development practices that made the whole reload/refresh nonsense irrelevant. Sorry, but I feel pretty strongly about this -- you talk to Alex, and Rich, and Stu, and folks like Eric Normand... none of them use this approach, none of them think it is needed. We need to teach people better REPL practices instead.

I personally would really much like to learn how to not need that! but most of the things in the “motivation” were biting me, before started to use the reloaded workflow.

maybe someone could write a point-by-point “how to do this without” guide?

that also btw spans how libraries are developed, for example, reitit doesn’t have a dev / repl-friendly mode (but it should), the router is always on prod-mode, e.g. compiles the route tree for performance - if you use reloaded workflow, just reset and it recompiles. If you don’t have, it’s not that much fun as changing any route snipplet requires you to reload the ns/def where the router is created.

We don't use alternative implementations for anything, but we still keep everything under polylith. All kinds of misc stuff goes to util component, though not nearly all of them does get used by every project. It's fairly small though, so we haven't even thought about splitting it yet.

we also have a test-util and util component. I think both of them have just a single macro currently. I don't really have an opinion on that pattern yet because neither of them are used in too many places yet. FWIW usually I try to avoid adding a util namespace because it's just too easy to push random stuff there. 😄

Good question. I feel something similar although I haven’t made tiny libraries yet. I feel some code is not repo specific (project is ambiguous here) and therefore shouldn’t be a component. Having it as a component clutters the components directory (visually). (Also I think you cannot nest components to fix this.) Then again I would like to have the benefits of a component, e.g. after I make a change to the library, tests of components that are dependent will be triggered on poly test. So I like the suggestion of @U8ZQ1J1RR as a middle ground. Another related question I think, what do you think about swappable libs? Code that is more like a library, used across repo’s, but that has multiple implementations for different contexts. Right now for instance, I’m working on an http abstraction component that has multiple implementations, depending on if you are runnning in production or development it has different properties (e.g. not allowing external requests or recording it). In setup a bit similar to https://github.com/clj-easy/tools.misc/tree/main/json

@U0FT7SRLP Funnily enough, one of our two swappable components right now in our monorepo at work is an http client abstraction that is implemented by Hato in one brick and by http-kit in another brick. We've done this for JDK8 compatibility (http-kit) because we still have code that has to be shared with a legacy app that must run on JDK8 (everything else runs on JDK18 at this point).

@U04V70XH6 Ah nice. My goal is to create a Ruby like experience where you use a dev http client that can record external interactions (using vcr-clj under the hood). And I would like to promote it so library authors will use this abstraction instead of choosing an arbitrary client (like clj-http, httpkit or aleph). This would allow to control http work at the root of your project

@U04V70XH6 Maybe it’s interesting to see if we can get to a common interface over these libraries and discuss it in a project like tools.misc (so we can use our own implementation https://github.com/weavejester/ring-oauth2/blob/master/src/ring/middleware/oauth2.clj#L77)