Fork me on GitHub
#announcements
<
2020-12-09
>
clyfe10:12:43

[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.

👍 5
mpenet14:12:37

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.

👍 1
beders15:12:43

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)

beders15:12:37

that way I don't have to make a translation from keyword to fn (which my IDE also doesn't understand)

clyfe16:12:20

(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.

👍 1
beders06:12:10

cool! Thanks for putting it in!

alidlorenzo14:12:55

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

metal 2
alexmiller15:12:56

I wish that had a rationale. I have no idea what problem it's trying to solve.

alexmiller15:12:57

(as someone that might be in a position to solve such a problem)

borkdude15:12:33

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

borkdude15:12:13

But then by generating a deps.edn on the fly

alexmiller15:12:17

I'm confused by the discussion of aliases in the readme

alexmiller15:12:45

well, I'm really asking @UPH6EL9DH

alidlorenzo15:12:50

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)

alidlorenzo15:12:39

i’ll try to make motivation/docs more clear when I get a chance

alidlorenzo15:12:16

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

alexmiller15:12:52

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)

alidlorenzo15:12:44

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

alidlorenzo15:12:59

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)

alexmiller15:12:57

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

alexmiller15:12:54

maven-style deps are no good for dev purposes. local deps solve some problems but create others.