Fork me on GitHub

I'm curious why polylith necessitate the :dev alias in the top-level deps.edn? when omitted, poly complains about the missing key.

👍 1

Several reasons, I expect. First off development is a project but doesn't have a folder and uses the workspace-level deps.edn instead but you control what's actually uses via aliases: not just :dev but also the profiles are aliases. Second, having your "REPL" deps under an alias means you can easily run other tooling in the repo without dragging in your entire codebase (and all of the deps from your bricks).


At work, we have a similar setup for our legacy subprojects in the repo (using an :everything alias as a parallel to Polylith's :dev alias -- which we were using before we started the migration so I had to rename it to avoid a conflict with Polylith's usage... and at first it was pretty much "everything" except for a few things under :dev as we started to migrate 🙂 ).


I think it's also fairly common in large projects for the :dev alias to be related to how you start your REPL for development across the whole project.


Perhaps the FAQ should have a Q&A about :dev?

👍 1

I see that it is natural and common, but don't see why it is a mandatory thing. For instance, I recently suggested a structure like below for development directory.

 ㄴsrc (contains user.clj for integrant)
 ㄴsrc (contains user.clj for integrant)
The main idea was to compose the development directory like components, and the top-level deps.edn looks like
{:aliases {:+name1 {:extra-paths ["development/name1/src"
                    :extra-deps  {poly/api-server   {:local/root "projects/name1-backend"}
                                  integrant/repl    {:mvn/version "0.3.2"}}}
           :+name2 {:extra-paths ["development/name2/src"
                    :extra-deps  {poly/api-server {:local/root "projects/name2-global"}
                                  integrant/repl  {:mvn/version "0.3.2"}}}


this approach aims to discard :dev and make aliases specific to servers that developers are interested in.


The real benefit is being able to work on the entire codebase from a single REPL -- if you want to work on just a project, you can start a REPL from the relevant projects folder (or you could add aliases that specified those projects as :local/root dependencies).

👍 1

Working on just part of the repo in a REPL is a non-goal with Polylith since that's already a solved problem, so to speak 🙂


yep, that is true. And that was the way we used to do. But I figured the top-level deps.edn can be much simplified with only one or two lines of code referencing projects with local/root, without having to include all components in extra-paths of :dev alias.


We don't use :extra-paths for :dev -- only for :test -- because we don't use Cursive so we don't need to work around that bug in Cursive.


So our library deps are all in the bricks' deps.edn files, and :dev is :extra-deps with :local/root for the bricks.


You have to list all the bricks somewhere so even if you push them out of the workspace deps.edn, they're just going to be somewhere else -- and I don't see that it's helpful to add "indirection" there and make it so you need to consult a bunch of deps.edn files to find where bricks should be referenced from?


The complain wasn't from cursive, but from the poly tool. It requires the name of all components written in the extra-paths. I think the information on which components a project refers to should be found in the project's deps.edn file, not from the top-level deps.edn file. Wouldn't it be more clear to have just the name of projects written with an alias, say api-server , than to write all the components the project is using?


This all makes sense to me on the setup with the bricks referencing their own deps, but does this apply to bricks that reference other bricks? For instance, we have many bricks that reference a common database brick. Should those bricks reference the database brick directly as well? It seems like they should as then you can even start a repl in an individual bricks directory but the realworld examples don’t seem to show that.


Bricks do not need to declare dependencies on other bricks. That's all handled at the project level (including the development project). Bricks should declare their 3rd party library dependencies only.


@U01TFN2113P My comment about Cursive was that it doesn't support :extra-deps / :local/root in the :dev alias as source components -- and you have to add all the bricks as :extra-paths instead -- and then you also have to add all of the 3rd party libs as :extra-deps to projects which is a lot of unnecessary duplication.


@U06BU61PZ The reason for that is that different projects can select different interface implementations -- swappable components -- and we leverage that at work so that projects can use one of two different HTTP client components and one of two different i18n components.


That makes sense. Thanks @U04V70XH6!


Got it! so to sum up, • poly tool mandates :dev alias because it is poly's intention to be able to access the whole codebase from a single REPL. • If one wants project specific REPL, one can set an alias specific to the project. (which is what I was doing) • Using cursive, one can't use local/root in the :dev alias.


Yup on #1 and #3. Not quite sure what you mean by #2 since you could just cd projects/foo && clj to start a basic REPL -- but presumably you want additional tooling?


Yep. We are using integrant with server for reloaded workflow, which is only needed for development environment.


Heh, you probably know my feelings on that reloaded workflow 🙂

🙂 1