Replies: 33 comments 96 replies
-
|
Interceptor model twist by @helins: https://gist.github.com/helins/de21872849d4149282dbcfeec49a41bf Interceptor model by @stevebuik: (defn run!
[{:keys [verbose]} steps]
(let [all-results (atom {})]
(doseq [step steps]
(let [{:keys [action success?]} step
result (action @all-results)]
(println)
(println ">>" (:name step))
(when verbose
(pprint result))
(if (success? result)
(swap! all-results assoc (:name step) result)
(throw (ex-info "action failed" result)))))
(println)
(println "Success!")))
(utils/run! options
[{:name :get-tag
:action utils/step-get-git-tag
:success? (fn [result]
(not (nil? (:latest-commit-tag result))))}
{:name :get-sha
:action utils/step-get-git-sha
:success? (constantly true)}
{:name :compress-main-js
:action (fn [_]
(utils/compress-file! "./public/client-js" "main.js"))
:success? (fn [result]
(> (:size-compressed result) 0))}
{:name :deploy-editor-js
:action (fn [results]
(let [sha (get-in results [:get-sha :sha])]
(utils/deploy-compressed-asset-to-s3!
{:region bucket-region
:content-type "application/javascript"}
"main.js.gz"
(str "/editor/main." sha ".js"))))
:success? (fn [result]
(nil? (:Error result)))}
]) |
Beta Was this translation helpful? Give feedback.
-
|
Mach took the idea of make / Makefile and made it into a ClojurreScript version: |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking instead of |
Beta Was this translation helpful? Give feedback.
-
|
Of course we are reaching the realm of personal opinion but what does the "code" version truly provide over the EDN "declarative" approach which allows for calling custom BB scripts? |
Beta Was this translation helpful? Give feedback.
-
|
The code is rather small so I think porting to babashka (and possibly incorporating a version of that in babashka) would be pretty straightforward. |
Beta Was this translation helpful? Give feedback.
-
|
@borkdude what would be the reason for hiding this EDN file under a hidden Also, is there a discussion somewhere about the goal of this |
Beta Was this translation helpful? Give feedback.
-
|
@onetom That is something I have considered, but I think typically people use a different set of deps for bb than for Java. Sticking / merging everything in the deps.edn file that I might want to support for babashka in the future might be awkward. E.g. Dependencies for babashka would live under an alias?
What if you want to invoke aliases for babashka deps itself, you can't nest aliases? All in all, I think it might be worth having a bespoke |
Beta Was this translation helpful? Give feedback.
-
|
About hidden: This is what I've chosen for clj-kondo:
The benefit of this is that you can store more stuff in that directory. E.g. clj-kondo stores its cache files there. But following the mainstream dependency tools, having a top-level |
Beta Was this translation helpful? Give feedback.
-
|
@onetom Btw, I have some issues here: https://github.com/babashka/babashka/issues?q=is%3Aissue+is%3Aopen+label%3Abb.edn |
Beta Was this translation helpful? Give feedback.
-
|
The thing is, there is no such thing as a "general-purpose" build tool / task runner. It pays out to think about what are 95% of use-cases and target that instead of trying to be unnecessarily perfect.
By providing a way of running tasks in a sequence with a fail fast mechanism (usually, building anything should stop if anything fails), we are already covering much ground. Anything needing more complex logic can be encapsulated in a BB script (or whatever) anyways which would do heavy work, call several functions, maintain some state in-between... Otherwise, tasks should be fairly opaque units of work.
What would set apart a BB-based task runner from anything else and all those Make alternatives? It is essentially Clojure, it can speak EDN, and EDN is perfect for describing a build process. It is searchable, CI-friendly while remaining human-friendly. It could rather easily build an EDN report listing everything that happened, pinpointing the exact moment of failure. When calling a BB script task, that task could itself return EDN akin to a rich exit code, adding valuable information to that report. That is a life worth living. Even when calling a bash job, we could specify EDN data to select depending on the exit code.
Such ideas remain purely declarative and in my opinion already provide much more than common options. In other words, I believe there are more exciting things to do in an "EDN approach" before dreaming too big with a "code approach".
|
Beta Was this translation helpful? Give feedback.
-
|
Currently this is possible in the bb.edn branch: :never-failing-shell
{:task/type :babashka
;; we are executing a shell task, yet we are continuing despite the error code
:args [-e (-> (do (deref (babashka.process/process ["ls" "foobar"] {:inherit true}))
(deref (babashka.process/process ["echo" "done"] {:inherit true}))
nil))]}
:print-hello {:task/type :babashka
:args [-e (println :hello)]}
:always-failing-shell
{:task/type :babashka
;; we are executing a shell task, yet we are continueing despite the error code
:args [-e (babashka.process/check (babashka.process/process ["ls" "foobar"] {:inherit true}))]}
:composed-never-failing {:task/type :babashka
:args [:do :never-failing-shell
:__ :print-hello]}
:composed-failing {:task/type :babashka
:args [:do :always-failing-shell
:__ :print-hello]}So Machfile-like execution is simply done using $ BABASHKA_EDN=test-resources/bb.edn bb :composed-never-failing
ls: foobar: No such file or directory
done
:hello$ BABASHKA_EDN=test-resources/bb.edn bb :composed-failing
ls: foobar: No such file or directory
----- Error --------------------------------------------------------------------
Type: clojure.lang.ExceptionInfo
Message:
Location: <expr>:1:1
----- Context ------------------------------------------------------------------
1: (babashka.process/check (babashka.process/process ["ls" "foobar"] {:inherit true}))
^---
----- Stack trace --------------------------------------------------------------
user - <expr>:1:1 |
Beta Was this translation helpful? Give feedback.
-
|
I think we can add a |
Beta Was this translation helpful? Give feedback.
-
|
Subsequently tasks should be able request data from the context-map, not sure what would be the best syntax for this. Maybe {:task/type :shell
:args [#tasks/get-in [:java :executable] "--version"]}
:depends [[:find-java {:out [:java :executable]}]] |
Beta Was this translation helpful? Give feedback.
-
|
It's starting to look a little bit like re-frame or perhaps pathom... |
Beta Was this translation helpful? Give feedback.
-
|
So |
Beta Was this translation helpful? Give feedback.
-
|
@helins Just improvising about
And once that task is done, we can fetch it from the context map with |
Beta Was this translation helpful? Give feedback.
-
|
Hmmm, improvising as well I would prefer something more decoupled. Basic tasks without any dependencies between them: :find-java
{:task/type :shell
:args ["which" "java"]}
:print-java-version
{:task/type :shell
:args [:path "-version"]}
;; Notice the `:path` keyword "input"And now, a task which is actually a runner: {:task/type :runner
:tasks [:find-java
[:print-java-version {:pipe {:find-java :path}}]]}A task always output data to the context, the key being its name. Doing so, tasks are declared in an entirely decoupled fashion. We couple them only when composing them. We could even reuse And we can easily compose several |
Beta Was this translation helpful? Give feedback.
-
|
That is putting aside for a moment things like fail-fast Vs continue on failure and so one. Here I focus on ordering, reusability, and dependency. |
Beta Was this translation helpful? Give feedback.
-
|
I have the feeling we are inventing a language like Clojure here, but written in EDN. This is the reason I started writing a Clojure interpreter instead of continuing my jet query DSL: https://github.com/borkdude/jet/blob/master/doc/query.md I figured people just wanted to use a language they already know and not learn a new one. That's why I built babashka ;). |
Beta Was this translation helpful? Give feedback.
-
|
It is a surprisingly complex topic, isn't it? What do you suggest, putting it aside for a while, let the idea mature? |
Beta Was this translation helpful? Give feedback.
-
|
My initial idea was to have better support for babashka multi-file projects:
E.g. in this project: https://github.com/babashka/pod-registry/tree/master/script I would run That same script is re-used in this one: Using bb.deps I would run it like this: and while putting the deps inside I hadn't considered the Makefile related things and task-interactions yet. |
Beta Was this translation helpful? Give feedback.
-
|
I guess we can start with the uncontroversial bits of
|
Beta Was this translation helpful? Give feedback.
-
|
This is certainly the most democratic solution for a good starter. I have a preference for Multiple entrypoints is always useful, especially for scripting utilities. On a different note, I would fancy something for helping discoverability and usage. It's always a bit frustrating working with someone's else repo, there is a lot of guessing on what scripts do and how to use them. Even in a personal repo it gets cumbersome when I have lots of small scripts. It would be extra nice being able to print docstrings for public syms find in scripts, or target a given one as a refresher, quickly from the command-line. Maybe allow adding metadata to a sym for specifying that a fn can be an entrypoint? |
Beta Was this translation helpful? Give feedback.
-
Interesting question, for my projects my bb sources are currently always under |
Beta Was this translation helpful? Give feedback.
-
|
We can add the default |
Beta Was this translation helpful? Give feedback.
-
|
OK, not adding a default dir: this is a choice we can make later and not have to make now. People can add in |
Beta Was this translation helpful? Give feedback.
-
This is kind of what the task runner was attempting to solve: overview and description of all tasks (script or main invocations) |
Beta Was this translation helpful? Give feedback.
-
|
Interesting blog post by JUXT on how they are using bb + make: |
Beta Was this translation helpful? Give feedback.
-
|
I updated #756 with a problem statement and a proposed solution. Feedback is welcome here. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome feature! |
Beta Was this translation helpful? Give feedback.
-
|
I don't think this particular implementation would solve that issue since listing the classpath as declared in bb.edn would not list built-in libraries. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe an optional flag that list bb built-in libs? like |
Beta Was this translation helpful? Give feedback.
-
|
yeah, that could work! |
Beta Was this translation helpful? Give feedback.
-
|
@borkdude I just read your updates to #756. A pleasure to read - so succinct and clear! I don't know if you need to answer these questions in your overview, but I wondered (with my naive reader hat on):
And to capture some highlights of our brainstorming session (not suggestions for initial release):
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks!
|
Beta Was this translation helpful? Give feedback.
-
Maybe you are right. I was thinking of rewrite-clj usage where I leave all dev tasks unqualified so most commonly used tasks take less keystrokes, and qualified tasks for other things like ops. My proposed sorting strategy would group tasks when listed, so instead of something like: :adevtask1
:adevtask2
:ops/that
:ops/this
:verygooddevtask3
:verygooddevtask4I'd have: :adevtask1
:adevtask2
:verygooddevtask3
:verygooddevtask4
:ops/that
:ops/thisBut I am only imagining rewrite-clj usage and this might not be a good general approach. |
Beta Was this translation helpful? Give feedback.
-
|
Updated bb.edn branch with sorting of tasks and added a Renamed |
Beta Was this translation helpful? Give feedback.
-
(UX issue) Better feedback when user provides an unexisting taskBecause of the use of a colon I would expect |
Beta Was this translation helpful? Give feedback.
-
|
Fixed in bb.edn branch. |
Beta Was this translation helpful? Give feedback.
-
(UX issue) Better feedback when user provides invalid task format{:tasks {:foo [:task/type :babashka
:task/description "adf"
:task/args [-e (println "Hi")]]}} When listing tasks When invoking Expectation would be to get some feedback on the invalid format here. Maybe a data validation error ("not a map"). Especially in the beginning this might be confusing. |
Beta Was this translation helpful? Give feedback.
-
|
I think this can be covered in clj-kondo eventually. It already has a linter for |
Beta Was this translation helpful? Give feedback.
-
Alternative to the use of
|
Beta Was this translation helpful? Give feedback.
-
|
Startup is negligible indeed when you are not loading large libraries which take 300ms to load. But this is relatively rare so your argument is valid for the mainstream use case of babashka. We can keep Perhaps later we can add And then not support the We can keep the |
Beta Was this translation helpful? Give feedback.
-
|
One other issue: You write a lib, like an http server and you write a bb.edn for it, so you can easily invoke it with bb. I'm considering something like https://shadow-cljs.github.io/docs/UsersGuide.html#deps-edn So libs can have a deps.edn + a bb.edn runner which merges in the settings from deps.edn automatically. |
Beta Was this translation helpful? Give feedback.
-
|
Hiccup/malli style syntax, less verbose, maybe better: {:vars {:ci #eval (System/getenv "CI")
:artifact "out/foo.jar"
,}
:tasks
{:test [:do
[:shell "clojure" "-M:outdated:nop:1.8" "--exclude=clojure/brew-install"]
[:shell "clojure" "-M:dev:1.9:test"]
[:shell "clojure" "-M:dev:test"]]
:clean [:shell {:pre (do (println "Going to clean up") true)
:post true} ;; always return true, regardless if the shell command succeeded
"rm" "-rf" ".cpcache" "target"]
:deploy [:do
{:depends [:test :clean]}
[:shell {:pre (not #ref [:vars :ci])} "echo" "Deploying"]
[:shell "clojure" -X:deploy :installer :remote :artifact #ref [:vars :artifact]]]}} |
Beta Was this translation helpful? Give feedback.
-
|
Adding a For instance, considering tasks B and C which both depend on A. We could be smart and dedupe A, executing it only once. But what if A needs to be executed each time, which is not uncommon either? Should we introduce new syntax? |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Anyway, the point of the post was more about the hiccup-style syntax. Trying to port the antq Makefile (listed above) gets pretty verbose when porting it to the tasks DSL with |
Beta Was this translation helpful? Give feedback.
-
|
Rewrote the code in the bb.edn branch and documentation in #756 to hiccup-style syntax. {:paths ["test-resources/bb-edn"]
:deps {medley/medley {:mvn/version "1.3.0"}}
:tasks {:shell1 ^{:description "Echo hello"}
[:shell "echo" "hello"]
:shell2 ^{:description "Echo bye"}
[:shell "echo" "bye"]
:medley ^{:description "Show off medley"}
[:babashka -e (do (require (quote [medley.core :as m]))
(m/index-by :id [{:id 1} {:id 2}]))]}
,}This is especially convenient for inline tasks: [:do
[:shell "clojure" "-M:outdated:nop:1.8" "--exclude=clojure/brew-install"]
[:shell "clojure" "-M:dev:1.9:test"]
[:shell "clojure" "-M:dev:test"]]
|
Beta Was this translation helpful? Give feedback.
-
|
I would like to suggest something along the lines of your original idea, but with Another idea might be to allow tasks with no description or help to be just specified as a vector: |
Beta Was this translation helpful? Give feedback.
-
|
@jkrasnay This syntax has already been superseded by hiccup syntax, see below. What do you think of: {:tasks {:hello [:shell {:description "Say hello"}
"echo" "hello"]
:goodbye [:shell "echo" "goodbye"]}} |
Beta Was this translation helpful? Give feedback.
-
|
I suppose I like Also, Hiccup attributes are also needed by child tags, while task metadata like This is a really minor nit, though. The Hiccup/Malli style is not bad. |
Beta Was this translation helpful? Give feedback.
-
|
@jkrasnay I went with: {:tasks {:hello {:description "Say hello"
:task [:shell "echo hello"]}
:goodbye [:shell "echo goodbye"]}}now. As a bonus: the |
Beta Was this translation helpful? Give feedback.
-
|
Cool! Looks great! |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I am excited to be playing with current SNAPSHOT. Do you want small nits and observations as I see them at this point?
|
Beta Was this translation helpful? Give feedback.
-
|
Aside: Not suggesting that bb take this approach, but kaocha did something interesting for wordy vs succint configs for its tests.edn. |
Beta Was this translation helpful? Give feedback.
-
|
@lread Can you give an example of wordy vs succint? That document is kinda ... wordy. |
Beta Was this translation helpful? Give feedback.
-
|
Ha! Ya probably does not apply to bb, but thought I should reference just in case it stirred any ideas for you. Relevant bit from kaocha link:
For example my test-doc-blocks ;; kaocha config for clj testing
#kaocha/v1
{:plugins [:kaocha.plugin/hooks]
:tests [{:id :unit
:test-paths ["test"]
:skip-meta [:integration]}
{:id :integration
:test-paths ["test"]
:focus-meta [:integration]}
{:id :generated
:test-paths ["target/test-doc-blocks/test"]
:kaocha.hooks/post-load-test [lread.test-doc-blocks.kaocha.hooks/fail-on-no-tests-found]}]
:reporter kaocha.report/documentation
:randomize? false}But could have been written in long form: {:kaocha.plugin.randomize/randomize? false,
:kaocha/reporter kaocha.report/documentation,
:kaocha/color? true,
:kaocha/fail-fast? false,
:kaocha/plugins
[:kaocha.plugin/randomize
:kaocha.plugin/filter
:kaocha.plugin/capture-output
:kaocha.plugin/hooks],
:kaocha/tests
[{:kaocha.testable/desc "unit (clojure.test)",
:kaocha.testable/type :kaocha.type/clojure.test,
:kaocha.testable/id :unit,
:kaocha/ns-patterns ["-test$"],
:kaocha/source-paths ["src"],
:kaocha/test-paths ["test"],
:kaocha.filter/skip-meta [:kaocha/skip :integration]}
{:kaocha.testable/desc "integration (clojure.test)",
:kaocha.testable/type :kaocha.type/clojure.test,
:kaocha.testable/id :integration,
:kaocha/ns-patterns ["-test$"],
:kaocha/source-paths ["src"],
:kaocha/test-paths ["test"],
:kaocha.filter/skip-meta [:kaocha/skip],
:kaocha.filter/focus-meta [:integration]}
{:kaocha.testable/desc "generated (clojure.test)",
:kaocha.testable/type :kaocha.type/clojure.test,
:kaocha.testable/id :generated,
:kaocha/ns-patterns ["-test$"],
:kaocha/source-paths ["src"],
:kaocha/test-paths ["target/test-doc-blocks/test"],
:kaocha.filter/skip-meta [:kaocha/skip],
:kaocha.hooks/post-load-test
[#'lread.test-doc-blocks.kaocha.hooks/fail-on-no-tests-found]}],
:kaocha/cli-options {:config-file "tests.edn", :print-config true},
:kaocha.plugin.capture-output/capture-output? true} |
Beta Was this translation helpful? Give feedback.
-
|
That is quite wordy indeed... Note that |
Beta Was this translation helpful? Give feedback.
-
|
Hmm... interesting, I expect that plexus is probably aware, but he is planning a v2. Probably worth pinging him. I can do. |
Beta Was this translation helpful? Give feedback.
-
|
A benefit of bb tasks that I am seeing is that I am thinking more about how will I make an operation clear and usable for its audience. And... loving not having to |
Beta Was this translation helpful? Give feedback.
-
|
Observation: As I move each script to a task I find I am deleting: Because that's not the way the operation is invoked anymore. |
Beta Was this translation helpful? Give feedback.
-
|
That's still a nice to have for "single scripts" but when you have multiple bb tasks might be handier indeed. |
Beta Was this translation helpful? Give feedback.
-
|
Yup, certainly still nice to have. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure if this is a result of current bb 3.1 work, but I am moving from: (defn main [args] ...)
(main *comand-line-args*)To: (defn -main [& args] ...)Which is more of what I am used to from Clojure, which I like. |
Beta Was this translation helpful? Give feedback.
-
|
Note that you can also use That pattern is documented here: |
Beta Was this translation helpful? Give feedback.
-
|
Very small observation: not sure if you want to align help like lein does: I think it makes things easier to read. I am finding as I work through rewrite-clj tasks I am usually using the Here's my current tasks: What I'd prefer, maybe, is alignment like so: Or maybe like: Just ideas as they come to me. |
Beta Was this translation helpful? Give feedback.
-
|
I've completed my first pass through rewrite-clj with bb 3.1. I found myself making use of qualifiers on tasks to group them: Work saved here, here's the commit. I was thinking of replacing script/ci_tests.clj entirely with tasks, might give that a try tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
@lread Some feedback: note that anytime you write |
Beta Was this translation helpful? Give feedback.
-
|
Cool! Thanks for tips! |
Beta Was this translation helpful? Give feedback.
-
|
bb.edn branch updated with fixes for issues reported above, except for the docstring help formatting (todo). |
Beta Was this translation helpful? Give feedback.
-
|
Trying out today's 3.1 SNAPSHOT, much more readable > bb :tasks
The following tasks are available:
:import-vars - [gencode|check]
:lint
:outdated - report on outdated Clojure and npm dependencies
:ci/release - <args>
:ci/unit-tests
:doc/api-diffs - generate diff docs for rewrite-clj* APIs
:doc/cljdoc - <args> - preview what docs will look like on cljdoc
:doc/update-readme - honor our contributors in the README
:test/clj - [<args>]
:test/clj-watch - [<kaocha args>]
:test/cljs - [<args>] - run tests under ClojureScript
:test/cljs-shadow - run unit tests under shadow cljs
:test/cljs-watch - watch cljs tests with figwheel main
:test/coverage - generate code coverage reports for Clojure tests
:test/doc - test doc code blocks
:test/libs - [run|outdated] - verify that libs using rewrite-clj* work with current rewrite-clj
:test/native - run rewrite-clj and tests after compiled to GraalVM native image
:test/native-sci - interpret rewrite-clj tests via sci on a rewrite-clj native image
:test/native-sci-sanity - JVM only sanity test for :test/native-sci
Run bb :help <task> to view help of a specific task.Here are my notes from another experimentation run:
Today's changes are in this commit as I continue my experiments in this branch. Other observation:
|
Beta Was this translation helpful? Give feedback.
-
user=> (defn ^{:doc (str (+ 1 2 3))} foo [])
#'user/foo
user=> (doc foo)
-------------------------
user/foo
([])
6Having said that, would it be better to use which will print the docstring for the foo task or a var if it's not a task?
Other observation: 1. There might be an issue for it already, but if not, feel free to create one. |
Beta Was this translation helpful? Give feedback.
-
It could be that I am over-leary of dynamic metadata from my scars from using potemkin import-vars.
Actually, in absence of other points you are making, renaming |
Beta Was this translation helpful? Give feedback.
-
|
Another random bb tasks thought: I will likely rename my rewrite-clj This is merely an observation and something I have no issue with. |
Beta Was this translation helpful? Give feedback.
-
|
@lread Some updates:
{:tasks {:clean {:description "Foo" :task [:shell "rm -rf target"]}}}So, a top level map with
Let me know what you think. |
Beta Was this translation helpful? Give feedback.
-
|
Another minor change I'm considering: built-in tasks are symbols, user-defined tasks are keywords:
This again reduces the chance on conflicts. |
Beta Was this translation helpful? Give feedback.
-
|
This would maybe allow task extensions where qualified symbols can reference some task handler function in the future. |
Beta Was this translation helpful? Give feedback.
-
|
Made that change now too. |
Beta Was this translation helpful? Give feedback.
-
|
I was able to port antq's Makefile to bb.edn's new task runner: |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I agree. Working on a non-task branch now called |
Beta Was this translation helpful? Give feedback.
-
I think you meant |
Beta Was this translation helpful? Give feedback.
-
|
Correct. I renamed the file from runner.clj to tasks.clj later. |
Beta Was this translation helpful? Give feedback.
-
|
Now merged the first few changes for bb.edn + bb -m foo/bar to master. |
Beta Was this translation helpful? Give feedback.
-
|
Am trying this out from your antq branch. I agree that you'd want a So what have we dropped from our DSL exploration?
Random tasks thought:
|
Beta Was this translation helpful? Give feedback.
-
|
Trying out today's bb v3.1 SNAPSHOT (bb binary dated 4:39 PM).
Random bb tasks thoughts:
Today's changes are in this commit as I continue my experiments in this branch. |
Beta Was this translation helpful? Give feedback.
-
Workaround: This should be fixed I think, although it's not that common. @ random thoughts:
|
Beta Was this translation helpful? Give feedback.
-
|
This might not be relevant because a hammock/rethink might be going on, so please don't feel an obligation to respond, but:
Random |
Beta Was this translation helpful? Give feedback.
-
|
One thing I've been thinking about in the context of a task runner is the issue of scope. You might want to run tasks in ssh, or a container, or even a specific directory. |
Beta Was this translation helpful? Give feedback.
-
|
Now ported the tasks to normal functions: https://github.com/borkdude/antq/blob/bb.edn/script/tasks.clj The code is longer, but more flexible, so that may be the less controversial way to go.
Tasks can be discovered using (maybe warrants a Tasks can be invoked using: Docs: This all works with the code that's now on master. Let's continue in https://github.com/babashka/babashka/discussions/765 for feedback on bb.edn. |
Beta Was this translation helpful? Give feedback.
-
Let's post some ideas here about issue #756 and I will extract the relevant info into the issue.
/cc @stevebuik @helins
Beta Was this translation helpful? Give feedback.
All reactions