It seems that Broadway decided to include "Testing things" (please correct me here because that is my interpretation and assumption) https://github.com/dashbitco/broadway/blob/1a628df28a246a0a94101566c9fa5d047974388f/lib/broadway.ex#L1047 that will be useful only in the test environment.
The ideal scenario is that we figure out how to reflect such intention without having to lean on understanding and hidden intention type of thing. What would be an answer for that situation? On Monday, August 16, 2021 at 4:55:18 PM UTC-4 [email protected] wrote: > The current idiom for this that José mentions is, in my opinion, superior > to the proposed approach. > > It is still declarative, but at the code level rather than a data-driven > config level within mix, which makes it much more flexible. Ie, it lets > more complicated checks occur, can reference application config for values, > can report library-specific warnings/error messages rather than generic > mix-level ones. > > > I would create an application that sits in the middle and works as an > adapter that knows how to interface with both libraries > > I've seen an even simpler single-file single-module adapter implementation > for this that I quite like; something like this > <https://gist.github.com/christhekeele/7e1f3d73d51e5fb871e51e438df95c47>. > > > > On Saturday, August 14, 2021 at 2:50:38 PM UTC-7 [email protected] > wrote: > >> For sure, I knew about it because I learned from there actually. I love >> to have a more declarative way to express the intention, I feel we could >> embrace sharing TestSupport files more often if it was easy enough to do >> so. You got the idea, not sure what the direction should be, I trust you on >> that one. >> >> On Saturday, August 14, 2021 at 3:25:25 AM UTC-4 Wojtek Mach wrote: >> >>> On August 14, 2021, "gmail.com" <[email protected]> wrote: >>> >>> I was about to create another thread kind of related to this, please my >>> apologies if I misunderstood. >>> >>> Recently I started working on a package, and I wanted to share as part >>> of the package a lot of TestSupport codes that people would take advantage >>> of in testing. So the dilemma I am having is where to put that TestSupport >>> files: >>> >>> >>> This is something that ecto_sql does too. :) See >>> https://github.com/elixir-ecto/ecto_sql/blob/v3.6.2/integration_test/pg/all_test.exs#L1:L2. >>> >>> Notice we _require_ the files to compile them, they are not compiled >>> because they are not in the `elixirc_path` by default. You just need to >>> remember to include integration test stuff in your package: >>> https://github.com/elixir-ecto/ecto/blob/v3.6.0/mix.exs#L49. >>> >> -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/eaa94fcb-b1e0-4be6-9979-b42ae63daef3n%40googlegroups.com.
