[ANN] Tape Framework pre.alpha: kind of like Duct but for Frontend Announcement https://github.com/tape-framework/doc/blob/master/ANNs/0-pre.alpha.md, tutorial https://github.com/tape-framework/doc/blob/master/docs/Tutorial.md, example app https://github.com/tape-framework/7guis, project https://github.com/tape-framework/. Gist is: Reagent + Re-Frame + Integrant system out of a Module system (ported from Duct) + an experimental interface to Re-Frame + some extra tooling + a body of recipes.
@beders Your idea turned out great! https://github.com/tape-framework/mvc/commit/f85fe6b56a3287b5b0f699c87da593dad1d2f8dd
cool! Thanks for putting it in!
fyi there's a (clj) "tape" library out there already https://github.com/mpenet/tape If you want to do some SEO you might want find another name; or not, personally I don't mind.
Releasing Interdep, a library that helps you intercept a monorepo’s deps.edn
configs, so as to provide a sane, documented way of managing multiple subrepo deps and aliases.
Many libraries out in wild use Leiningen for monorepo support. Intention of this library is to serve as stop-gap solution using only tools.deps.
https://github.com/rejoice-cljc/interdep
I wish that had a rationale. I have no idea what problem it's trying to solve.
(as someone that might be in a position to solve such a problem)
This library came up in #tools-deps before. It tries to solve the multi-repo problem that people have tried to fix with CLJ_CONFIG
But then by generating a deps.edn on the fly
I'm confused by the discussion of aliases in the readme
is this the same problem as https://ask.clojure.org/index.php/9849/teams-common-dependencies-tooling-across-multiple-projects
yes
well, I'm really asking @alidcastano
so it solves two problems
1. using the nested aliases of subrepo deps, since with default functionality local dep aliases are not activated.
2. calling multiple aliases can be tedious (e.g. :app-main:api-main)
, so we also match aliases based on configured profiles (http://e.ga :main
profile for matching the those aliases)
i’ll try to make motivation/docs more clear when I get a chance
a third problem, btw, is that using local:root
deps is not always possible if deployment needs to be reproducible, so in that situation you also need a tool that unifies nested configurations
these seem like different problems than the ask question above. if there are good problems here, filing an ask question that asks it would be helpful to me. I'm not sure the problems you list are really the problems though, seems like could dig deeper. (like why do you need to invoke nested aliases of subrepo deps? what do those aliases do? etc)
one basic scenario: I have an :app/test
and :api/test
alias, and I want to run them from root of project
another more opinionated scenario: I avoided putting subrepo deps in top-level :path
and :deps
, since they’re automatically loaded. instead, each subrepo puts all its deps under aliases, so I’d call the :app/main
and :api/main
aliases to load their deps before starting a program. reasoning for this choice, is that I wanted more control over what deps were loaded before starting a program from root
prior to Interdep, I was using :local/root
deps but had to configure all my subrepo deps/aliases in root deps.edn, basically defeating the purpose of separating logic into nested projects (as they were all configured in root, anyway, and had to be run together from there)
I kinda like the meta-data approach.. However, if you go down that route, I would also expect to see it being used in subscriptions. From one of the samples:
[celsius @(rf/subscribe [::temperature-converter.c/celsius])
Would have expected to see this:
(tape/subscribe temperature.converter.c/celsius)
that way I don't have to make a translation from keyword to fn (which my IDE also doesn't understand)
trying to be a little more generic, you have one conceptual project that is broken into multiple parts (here app and api) and you're trying to manage both their independent deps, and their per-component aliases, and dep relationships between the components
yes 🙂
maven-style deps are no good for dev purposes. local deps solve some problems but create others.
(defn tape-subscribe [f & args]
(let [{:keys [ns name] ::v/keys [sub]} (meta (var f))
kw (if (qualified-keyword? sub) sub (keyword (str ns) (str name)))]
(rf/subscribe (into [kw] args))))
;; (tape-subscribe temperature.converter.c/celsius)
Should work in the meantime I believe.