Fork me on GitHub

How do people manage and maintain their aliases? For example in one of our projects: To start a basic dev repl (with all configured customers data on the classpath) you need the aliases: -A:dev:test:cljs:prj/all For me to start a dev repl I need/want to add the extra aliases :cider:sc to those. To run the tests in CI or via kaocha you need: -A:kaocha:test:prj/all:cljs To build a specific release for a specific customer we need: -A:prj/customer-1:prod Plus there are various other configurations of aliases. Right now I tend to “document” these by having scripts e.g. ./bin/cider ./bin/repl ./bin/kaocha apply them. However this is opaque to the tooling. So cursive users have to manually select the specific aliases they want to translate the scripts to the aliases they want to use when they start a repl; and Emacs users need to run the right script with their own :cider alias appended and cider-connect to the repl. Then a different project will have different combinations. I find our alias definitions tend to become smaller over time, so they can be reused in other contexts — but then you end up with lots of small things that you have to remember to add back in when you start your REPL/tests/etc. It’d be nice if tools deps aliases could also be sets of aliases… e.g. I’d really like to define the following:

:composite-aliases {:dev #{:prj/all :test :cljs :user/dev}
   :prj/all #{:prj/customer-1 :prj/customer-2 :prj/customer-3 ,,,}
   :prod/customer-1 #{:prod :prj/customer-1}
   :prod/customer-2 #{:prod :prj/customer-2}}


Alias-aliases like that would be very handy sometimes.


At work @seancorfield wrote a shell script that manages a lot of that stuff for us. Outside of work I rely pretty heavily on shell history for that kind of thing (type it in once, that search for it in history to run it again forever after), which has the added benefit of working for things outside of clojure too, but is not really sharable for a team.


That script knows about the high-level aliases and expands them into the set of low-level ones. It also knows how to run multiple clojure commands in sequence, to simulate lein/boot's ability to run multiple commands in one go


I think you might be better off creating coarser aliases. It seems to often be the case then when you add a meta language to a system (in this case aliases in deps are an aggregate built on top of clojure functions, but you can draw a similar analogy with things like di systems) the meta language starts out providing a coarse aggregate of base level functionality, and then overtime becomes finer overtime until it corresponds so closely with the base level that you lose the aggregate functionality and start building a new meta level (:composite-aliases) to try and regain the aggregation


> I think you might be better off creating coarser aliases Yeah, I’ve tried that too. That’s essentially what the :prj/all alias is. It’s an alias that adds all (customer) project dependencies to the classpath; and it is essentially the union of all the customer aliases. I find it becomes hard to then know what deps/paths/config belong to which alias though… e.g. I’m a believer that in the repl you should have both :dev-tooling and :test stuff available. But :test may also want to be included in the alias the CI uses to run the tests. The problem then is that the groupings become lost, and you need to resort to comments to group things which is far from ideal.


like, maybe get rid of the separate alias for adding cider, add it to the class path for all the dev aliases, but add some kind of runtime configuration option so it only launches nrepl on developers machines that want it


@rickmoynihan 1. copy and paste 2. Not including things like cider in projects, that's userland stuff


I agree cider is userland stuff. We treat it as such. This adds a further complication that each user might define cider in a different alias, e.g. I have :cider-22 :cider-21.


You can probably configure cider to call clojure always as -A:cider <prompted arguments>.


Yeah I think you can do that but often we need to run the JVM in a particular environment, with env vars etc set… So I tend to prefer to cider-connect to an instance started in a terminal. I’ve solved some of the issues here by starting the dev repl and dependent services, along with shadow-cljs --watch etc with overmind; which uses a Procfile to start stuff; and allows you to share env vars across services. I then use direnv to share project wide, not just repl wide, configuration… e.g. a port/location of a shared database across services etc.


Dev/test/cljs would probably be copy and pasted into each other as much as they were mutually dependent.


I'm not sure what's different between customers for you, so it's hard to say what I'd do


Mainly just assets on the resource path; and occasionally customer specific reference data.


Though some of those assets are bundled into webjars… e.g. css skins.