As I mentioned, the issue on transitive compile-time dependencies are the compile-time deps, not the runtime ones. So I would focus on how to eliminate those. Otherwise I am not sure we will agree on the problem statement. :)
On Wed, Sep 14, 2022 at 12:49 AM Zach Daniel <[email protected]> wrote: > Although the solution I originally proposed may not be correct (totally > fine with me [image: 😃]), I think the problem statement is still valid. > Can we agree that there are some cases where you may want to reference a > module without creating transitive compile time dependencies, i.e in the > case of a DSL like what Ash provides? > > > On Sun, Sep 11, 2022 at 3:08 PM, Zach Daniel <[email protected]> > wrote: > >> Hm...yeah, that makes sense. Are there other things a runtime dependency >> is meant to do aside from ensure that transitive compile time dependencies >> are properly tracked? If so, is there a way to solve for the transitive >> dependencies without removing the runtime dependency? Because ultimately >> the idea here is that this module is essentially just a big >> validated/extensible configuration. The resource itself doesn't do >> anything. So requiring things that refer to a resource to recompile when >> any of the modules it refers to in a `change` like that is unnecessary. >> However we can express that reality is totally fine with me. >> >> >> On Sunday, September 11, 2022 at 3:05:18 PM UTC-4 José Valim wrote: >> >>> The issue is in the transitive compile time dependencies, not the >>> runtime dependencies. >>> >>> I don't think we should be encouraging removing the runtime dependencies >>> when they are explicitly listed in the code as above. When done via >>> configuration, at least you are not literally listing it. >>> >>> On Sun, Sep 11, 2022 at 8:59 PM Zach Daniel <[email protected]> >>> wrote: >>> >>>> So all we we do is hold onto the module, and then at runtime we go >>>> through the list of modules that we should call and call a specific >>>> function on them. Requiring a runtime dependency for that is causing really >>>> slow compile times because of transitive dependencies. Maybe there is some >>>> consequence I don't see, but I removed the runtime dependencies by >>>> disabling the lexical tracker when expanding the alias, and its been that >>>> way for months w/o anyone reporting any issues with that implementation. >>>> Aside from having to use `warn: false` if they use aliases. >>>> >>>> To me, its the same as if they gave us, instead of a module, an `atom` >>>> that referred to application configuration, i.e the adapter pattern. That >>>> would work without a runtime dependency, so why couldn't this? >>>> >>>> >>>> On Sun, Sep 11, 2022 at 2:56 PM, José Valim <[email protected]> >>>> wrote: >>>> >>> Sorry, correction: If, at any moment, you call any function from that >>>>> module at runtime, you must not remove the *runtime* time dependency. >>>>> >>>>> On Sun, Sep 11, 2022 at 8:55 PM José Valim <[email protected]> >>>>> wrote: >>>>> >>>> Why do you want to remove the runtime dependency when, per your >>>>>> description: >>>>>> >>>>>> > In Ash Framework, we have declarative ways to construct *runtime* >>>>>> behavior using behaviors. >>>>>> >>>>>> Emphasis mine. If, at any moment, you call any function from that >>>>>> module at runtime, you must not remove the compile time dependency. >>>>>> >>>>>> On Sun, Sep 11, 2022 at 8:52 PM Zach Daniel <[email protected]> >>>>>> wrote: >>>>>> >>>>> `expand_literal` removes the compile time dependency, but leaves a >>>>>>> runtime dependency when used inside of a module. >>>>>>> >>>>>>> What I'm trying to do is remove both the compile time dependency >>>>>>> *and* the runtime dependency, without requiring the use of `warn: >>>>>>> false` on >>>>>>> aliases. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sunday, September 11, 2022 at 2:31:42 PM UTC-4 José Valim wrote: >>>>>>> >>>>>>>> Sorry, I don't understand the proposal. You mentioned >>>>>>>> expand_literal, which already removes the compile-time dependency but >>>>>>>> keeps >>>>>>>> the remaining functionality such as warnings. Can you please expand? >>>>>>>> >>>>>>>> On Sun, Sep 11, 2022 at 7:57 PM Zach Daniel <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> For clarity, the dependency I'm talking about there is the >>>>>>>>> dependency from `MyApp.User` to `MyApp.User.Changes.HashPassword`. >>>>>>>>> On Sunday, September 11, 2022 at 1:55:51 PM UTC-4 Zach Daniel >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> In Ash Framework, we have declarative ways to construct runtime >>>>>>>>>> behavior using behaviors. So an Ash resource might look like this: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ```elixir >>>>>>>>>> defmodule MyApp.User do >>>>>>>>>> use Ash.Resource >>>>>>>>>> >>>>>>>>>> alias MyApp.User.Changes.HashPassword >>>>>>>>>> >>>>>>>>>> attributes do >>>>>>>>>> uuid_primary_key :id >>>>>>>>>> .... >>>>>>>>>> end >>>>>>>>>> >>>>>>>>>> actions do >>>>>>>>>> create :register do >>>>>>>>>> change HashPassword >>>>>>>>>> end >>>>>>>>>> end >>>>>>>>>> end >>>>>>>>>> ``` >>>>>>>>>> >>>>>>>>>> However, by default, this would incur a compile time dependency. >>>>>>>>>> This compile time dependency is unnecessary, as we won't call any >>>>>>>>>> functions >>>>>>>>>> on this module or use it in any way until runtime. >>>>>>>>>> >>>>>>>>>> That optimization is well and good, but due to transitive compile >>>>>>>>>> time dependencies, we see some interesting behavior. Something you'd >>>>>>>>>> often >>>>>>>>>> see in a change module is things like pattern matching on other >>>>>>>>>> resources, >>>>>>>>>> or the resource in question in function heads. Resources are meant >>>>>>>>>> to be >>>>>>>>>> introspectable at compile time, and so this runtime dependency on a >>>>>>>>>> change, >>>>>>>>>> with a compile time dependency on a resource, incurs a transitive >>>>>>>>>> compile >>>>>>>>>> time dependency. This problem multiplies over time, and causes users >>>>>>>>>> to >>>>>>>>>> have to do things solely to optimize compile times, like only use map >>>>>>>>>> pattern matches instead of struct pattern matches. >>>>>>>>>> >>>>>>>>>> So what we do is we actually disable the lexical tracker when >>>>>>>>>> accepting certain parts of the DSL. This prevents *any* dependency. >>>>>>>>>> Naturally, at compile time you are no longer safe to call a >>>>>>>>>> resource's >>>>>>>>>> change module as changes in that module won't cause recompiles, but >>>>>>>>>> that >>>>>>>>>> was never a thing you should have done in the first place so I'm not >>>>>>>>>> worried about that. >>>>>>>>>> >>>>>>>>>> This leads us to the primary issue: disabling the lexical tracker >>>>>>>>>> when expanding aliases also causes warnings about unused aliases, >>>>>>>>>> even >>>>>>>>>> though they *are* used. I believe I've brought this issue up before >>>>>>>>>> and we >>>>>>>>>> were hoping that the feature introduced in 1.14 for `defimpl` would >>>>>>>>>> help, >>>>>>>>>> but that only helps prevent compile time issues, which is something >>>>>>>>>> I had >>>>>>>>>> already solved for in the same way it was solved for 1.14. I've laid >>>>>>>>>> it all >>>>>>>>>> out to help clarify exactly *why* I need it so perhaps someone can >>>>>>>>>> point me >>>>>>>>>> in a better direction. >>>>>>>>>> >>>>>>>>>> The simplest thing that could help: >>>>>>>>>> >>>>>>>>>> A way to tell the lexical tracker that an alias has just been >>>>>>>>>> referenced without inducing any kind of compile or runtime >>>>>>>>>> dependency. The >>>>>>>>>> idea is to just prevent it from warning about the alias. >>>>>>>>>> >>>>>>>>>> I'm open to other solutions as well. >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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/54627973-7b74-47d7-9e35-4270621e6c91n%40googlegroups.com >>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/54627973-7b74-47d7-9e35-4270621e6c91n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>>> 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/22887a7e-a1b6-4ccc-98bf-69a5ad3551a5n%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/22887a7e-a1b6-4ccc-98bf-69a5ad3551a5n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> 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/CAGnRm4%2BVkL%2B1V7LTDVyzhCqcNWrmHFPoWx2Fp916Ur%2ByL%2BiVBA%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BVkL%2B1V7LTDVyzhCqcNWrmHFPoWx2Fp916Ur%2ByL%2BiVBA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> -- >>>> 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/l7xp6eut.444ff913-f528-4b88-805a-cac120cdb4d6%40we.are.superhuman.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/l7xp6eut.444ff913-f528-4b88-805a-cac120cdb4d6%40we.are.superhuman.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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/072bb99d-09a0-4567-a934-f8893015dd91n%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/072bb99d-09a0-4567-a934-f8893015dd91n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > -- > 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/l80s9s37.13dfe243-83b3-4133-8aad-7a86910f56fa%40we.are.superhuman.com > <https://groups.google.com/d/msgid/elixir-lang-core/l80s9s37.13dfe243-83b3-4133-8aad-7a86910f56fa%40we.are.superhuman.com?utm_medium=email&utm_source=footer> > . > -- 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/CAGnRm4J8qxM%3DKxMUUW6X%2Bt%2BrD9rKn0yDHbDY1fDgopxRvtNn5A%40mail.gmail.com.
