This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-11-08
Channels
- # aleph (9)
- # announcements (42)
- # babashka (13)
- # babashka-sci-dev (9)
- # beginners (38)
- # biff (1)
- # calva (4)
- # cider (5)
- # clj-kondo (39)
- # cljdoc (4)
- # cljsrn (3)
- # clojure (93)
- # clojure-bay-area (1)
- # clojure-czech (1)
- # clojure-dev (4)
- # clojure-europe (65)
- # clojure-finland (3)
- # clojure-nl (2)
- # clojure-norway (7)
- # clojure-portugal (1)
- # clojure-uk (2)
- # clojurescript (73)
- # cloverage (1)
- # cursive (5)
- # data-science (1)
- # datahike (22)
- # emacs (51)
- # graalvm (6)
- # introduce-yourself (8)
- # jobs-discuss (14)
- # kaocha (6)
- # mount (5)
- # nbb (19)
- # off-topic (19)
- # reagent (5)
- # releases (1)
- # sci (19)
- # scittle (4)
- # shadow-cljs (6)
- # tools-deps (9)
- # xtdb (2)
Would it be possible to make manifold an optional (provided?) dependency in byte-streams? I feel dirty for pulling in half a ton of dependencies when I don't think I'm using async stream transformations at all
Something along the lines of splitting the manifold-dependent pushback stream conversions into a separate namespace and only loading them if manifold is on the classpath
Well, depending on your conversion pathway, you might still be using manifold internally.
Regardless, it could be done, but not easily. The pushback-related code isn't the real problem. Conditionally compiling the relevant def-conversion
s wouldn't be too hard either. No, the issue is the code isn't very polymorphic, so we'd have to weave a lot of conditional compilation macros through various functions. Also def
is a special form, and doesn't play too well with conditional compilation macros, iirc.
Requiring users to know they have to supply manifold is a breaking change, anyway. I would however, be fine with factoring the code out into sub-libraries, as long as the byte-streams API is the same. Then you could use the sublibrary
(Btw, we have a #C02H9GF74CF channel for this)
@UAEH11THP I don't have the time to tackle this, but byte-streams could use modernization, and this could be part of it. If you want to separate them, I could work with you on it.
Do you imagine something like the way many modular metosin projects are organized? Having a core
without the manifold dependency, a module with manifold and then having the "old" top-level library pull in all those?
I'm not that familiar with the metosin layout, but yes, something like that
what's up with the https://github.com/clj-commons/aleph/tree/1.0.0 branch? it looks very diverged from master