Yes, if you want something with maximal flexibility you’d use application
config and regular optional dependencies. The idea is to find a middle ground.
Because we cannot run arbitrary code every time we want to solve versions. A
package published to hex must know *all* potential dependencies.
On Tue, May 16 2023 at 2:19 AM, Yordis Prieto < yordis.pri...@gmail.com > wrote:
>
> It could be `Mix` rather than `Application.` I just used `Application`
> because of how `compile_env` works. Here is another example where I am
> curious about how the proposal would solve it:
>
>
> ```
> defmodule MyModule.ErrorBuilder do
>
> # notice here the macro
> defmacro __using__() do
> defstruct [....]
>
> # notice here the usage
> if Code.ensure_loaded?(Ecto) do
> def new(%Ecto.Changeset{} = changeset) do
> attrs =
> changeset
> |> ChangesetParser.parse()
>
> struct(unquote(__MODULE__), attrs)
> end
> end
> end
> end
> ```
>
> Also, I was thinking more around the lines of if Mix.feature?(:otp_name,
> :feature1) or Mix.feature?/1, not sure.
>
> I intended to highlight that Elixir is a fully turing completed scripting
> programming language to build Elixir code itself due to macro expansion. I
> don't know how you could define all the static information using features:
> [hls: [dependencies: [], modules: ]]] when the values depend upon
> Compile-Time macro expansion. It could even download an entire OpenAPI
> Spec YAML file and construct an entire module. I am not making things app,
> https://github.com/elixir-tesla/tesla_openapi (Protobuf, Avro, and many
> other things that could do the same), so situations as I described,
> including or not Jason encoding, among many other things, are real
> situations that will happen.
>
> `mix.exs#features` could put guide rails in the library code, enforcing to
> statically define the features, and use `Mix.ensure_feature!/2` to enable
> the such feature if you want the compilation branch to happen. It does not
> matter where you are at compile-time.
>
> I am sorry I am coming back to what I said before. Still, I am trying to
> figure out how the proposal would work, considering macro expansions
> depending upon the execution of the compilation and such compilation
> dictating the needs of the dependencies.
>
> I am going to observe from now on. I shared the last information I somehow
> forgot to share that was critical to making sense of whatever I was trying
> to do. My apologies. Hopefully, next time, my brain doesn't fail me.
>
> I am trying my best! I am sorry.
>
>
> On Tuesday, May 16, 2023 at 12:01:17 AM UTC-4 zachary....@gmail.com wrote:
>
>
>
>> I'd amend the proposal:
>>
>>
>>
>> To make a dependency only present when a feature is used
>>
>> ```elixir
>>
>> {:optional_dep, …, optional: [:feature1, :feature2]}
>>
>> ```
>>
>>
>>
>> To use a dependency with features
>>
>> ```elixir
>>
>> {:dep, …, features: [:feature1]}
>>
>> ```
>>
>>
>>
>> And then build features into `Mix` (which is available at compile time) or
>> `Application` similar to `Application.compile_env`. The reason it makes
>> sense to build it into `Mix` is that as José pointed out it will have to
>> be built into mix/hex for dependency resolution.
>>
>>
>> ```elixir
>>
>> if Mix.feature?(:feature1) do
>>
>> defmodule Foo do
>>
>> …
>>
>> end
>>
>> end
>>
>> ```
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, May 15, 2023 at 8:52 PM, Yordis Prieto < yordis...@gmail.com > wrote:
>>
>>
>>
>>> In cases, the following code may exist (real production code):
>>>
>>> ```
>>> defmodule MyModule.Error do
>>>
>>> # notice here
>>> if Code.ensure_loaded?(Ecto) do
>>> alias MyModule.Error.{ChangesetParser, ErrorList}
>>> @spec new(Ecto.Changeset.t()) :: MyModule.Error.ErrorList.t()
>>> def new(%Ecto.Changeset{} = changeset) do
>>> changeset
>>> |> ChangesetParser.parse()
>>> |> ErrorList.new ( http://errorlist.new/ ) ()
>>> end
>>> end
>>>
>>>
>>>
>>> end
>>> ```
>>>
>>> Based on your proposal, use the following structure:
>>>
>>> ```elixir
>>> features: [
>>> hls: [
>>> dependencies: [],
>>> modules: []
>>> ]
>>> ]
>>>
>>> ```
>>>
>>> How could we configure it to depend on `Ecto` only for that function?
>>> On Monday, May 15, 2023 at 2:22:51 PM UTC-4 christ...@gmail.com wrote:
>>>
>>>
>>>> > Is there any particular issue with the information I shared that
>>>> wouldn't help with the situation?
>>>>
>>>> Your thoughts are compelling and merit discussion!
>>>>
>>>>
>>>> It's just that there's a slippery slope in proposal conversations: between
>>>> discussing *a specific* proposal (in this instance, Michal's original
>>>> well-formulated one), and brainstorming and iterating on feedback to
>>>> arrive at a new specific proposal. It's a fuzzy line, but one we have to
>>>> draw at some point in any conversation as it goes on, as this mailing list
>>>> is only for specific proposals.
>>>>
>>>>
>>>> It's nothing personal—it's just time to move conversation around building
>>>> a new proposal to a more productive discussion-oriented forum, such as the
>>>> Elixir Forums, or direct chat/emails with others working on a new idea!
>>>> On Sunday, May 14, 2023 at 3:59:06 PM UTC-4 yordis...@gmail.com wrote:
>>>>
>>>>
>>>>> I thought that the ideas were around the topic. Is there any particular
>>>>> issue with the information I shared that wouldn't help with the situation?
>>>>>
>>>>>
>>>>> On Sunday, May 14, 2023 at 3:33:30 PM UTC-4 José Valim wrote:
>>>>>
>>>>>
>>>>>> No worries, I didn't interpret it as a command. But it is clear there is
>>>>>> an expectation issue: this mailing list should focus on concrete features
>>>>>> and implementations. Once someone submits a proposal here, they are
>>>>>> probably expecting a yes, no (and why so), or what needs to be
>>>>>> considered/improved for the proposal to be accepted. So all feedback in
>>>>>> here has been direct (and historically it has not been a problem).
>>>>>>
>>>>>>
>>>>>> I recommend the Elixir Forum if the goal is to bounce ideas and explore
>>>>>> the problem space. We (the Elixir team) already have a lot on our hands
>>>>>> and we probably won't be able to develop ideas into full proposals. So I
>>>>>> don't want your trust to be misplaced. :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> > if we make assumptions and take the position of "it is possible today
>>>>>> > ,"
>>>>>> how could we discuss the trade-offs?
>>>>>>
>>>>>>
>>>>>> The point of saying "it is possible today " is that, if you are going to
>>>>>> propose something new, then at least it needs to be compared to what is
>>>>>> possible today and explain how it improves on that. This, alongside the
>>>>>> problem statement, is very important to ensure we are all on the same
>>>>>> page.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, May 14, 2023 at 8:08 PM Yordis Prieto < yordis...@gmail.com >
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> > Here is the issue: the proposal has not elaborated on how those
>>>>>>> > problems
>>>>>>> will be tackled (outside of dependency management).
>>>>>>>
>>>>>>> I wasn't trying to be in Solution-space, just sharing some ideas and
>>>>>>> pain
>>>>>>> points and trying to figure out if they could be solved simultaneously.
>>>>>>>
>>>>>>> > And don’t ask us to figure it out
>>>>>>>
>>>>>>> When I said, "I trust you will figure it out," I trusted you would do
>>>>>>> the
>>>>>>> right thing. I didn't give you any command. My apologies if it came
>>>>>>> across
>>>>>>> as a Command, but I intended to say, "I trust you, but please don't
>>>>>>> discourage the ideas making assumptions about it" That's all.
>>>>>>>
>>>>>>> > It is not that we don’t care or didn’t think about it. Those are
>>>>>>> different trade-offs, with their strengths and weaknesses, and if we
>>>>>>> want
>>>>>>> to copy features from Rust, then those trade-offs need to be taken into
>>>>>>> account as part of a complete proposal.
>>>>>>>
>>>>>>> I don't disagree with that at all. That was the intent; discuss it. But
>>>>>>> if
>>>>>>> we make assumptions and take the position of "it is possible today ,"
>>>>>>> how
>>>>>>> could we discuss the trade-offs?
>>>>>>>
>>>>>>> > Application.ensure_feature would most likely be a wrapper around
>>>>>>> > config.
>>>>>>>
>>>>>>>
>>>>>>> I am not sure about the technicality underneath, but I was assuming that
>>>>>>> we can't just do that unless we reserve some key or something like that,
>>>>>>> so I was thinking in a completely different ets table for it, but sure,
>>>>>>> it
>>>>>>> could "feel" as simple as Config module, why not.
>>>>>>>
>>>>>>> One way I was thinking of adding a key under the `mix.exs` to be able to
>>>>>>> have information:
>>>>>>>
>>>>>>> ```
>>>>>>> defmodule H264.MixProject do
>>>>>>> use Mix.Project
>>>>>>>
>>>>>>> def project do
>>>>>>> [features: [:parser, :encoder, :native]] # maybe be able to add
>>>>>>> description for them also?!
>>>>>>> end
>>>>>>> end
>>>>>>> ```
>>>>>>>
>>>>>>> Be able to use that information when calling
>>>>>>> `Application.ensure_feature`.
>>>>>>> It would be just the Config API since it would require checking
>>>>>>> `mix.exs`
>>>>>>> and/or another ets table with the information about the feature. I guess
>>>>>>> that registering the Features at compile time instead of being
>>>>>>> statically
>>>>>>> defined in the `mix.exs` would become harder. I am unsure if that would
>>>>>>> be
>>>>>>> a good idea.
>>>>>>>
>>>>>>> ExDoc and the Mix.Deps task could read such information to require
>>>>>>> dependencies or have documentation about it. It could be used behind
>>>>>>> `Config` package under another macro:
>>>>>>>
>>>>>>> ```
>>>>>>> import Config
>>>>>>> feature :h264, encoder: true
>>>>>>> ```
>>>>>>>
>>>>>>> Or don't do that at all and you only get to activate them using `deps`
>>>>>>> and
>>>>>>> mess around with `Mix.env()` to correctly configure the features.
>>>>>>>
>>>>>>> Probably activating "statically" in the mix.exs would be simple and
>>>>>>> easier
>>>>>>> to deal with.
>>>>>>>
>>>>>>>
>>>>>>> defmodule MyApp.MixProject do
>>>>>>> use Mix.Project
>>>>>>>
>>>>>>> def project do
>>>>>>> [
>>>>>>> deps: [
>>>>>>> {:h264, "~> 0.10.0", features: [:encoder]}
>>>>>>> ]
>>>>>>> ]
>>>>>>> end
>>>>>>> end
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sunday, May 14, 2023 at 3:18:01 AM UTC-4 michal...@gmail.com wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Sure thing, I just wrote as I thought that maybe you will say: that's a
>>>>>>>> good idea, we were thinking about it, we had similar problems etc. etc.
>>>>>>>>
>>>>>>>>
>>>>>>>> But because of a lot of questions and doubts it's clear that's the
>>>>>>>> requester responsibility to propose detailed description of the API,
>>>>>>>> take
>>>>>>>> into account all pros and cons, describe how they will affect the whole
>>>>>>>> ecosystem and whether the requested feature fits into the language
>>>>>>>> concepts
>>>>>>>>
>>>>>>>>
>>>>>>>> niedz., 14 maj 2023, 08:58 użytkownik José Valim < jose....@dashbit.co
>>>>>>>> >
>>>>>>>> napisał:
>>>>>>>>
>>>>>>>>
>>>>>>>>> One addition: “features” makes sense for Rust because the contents of
>>>>>>>>> its
>>>>>>>>> “module body” cannot be dynamic as in Elixir. So if they want to
>>>>>>>>> provide
>>>>>>>>> this feature in the first place, it must be done as part of the
>>>>>>>>> compiler.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Elixir can execute any Elixir code when defining modules, which is
>>>>>>>>> why it
>>>>>>>>> is possible to implement these features today without additional work
>>>>>>>>> in
>>>>>>>>> the compiler.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is not that we don’t care or didn’t think about it. Those are
>>>>>>>>> different
>>>>>>>>> trade-offs, with their own strengths and weaknesses, and if we want to
>>>>>>>>> copy features from Rust, then those trade-offs need to be taken into
>>>>>>>>> account as part of a complete proposal.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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 elixir-lang-co...@googlegroups.com.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> To view this discussion on the web visit
>>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LeSido9jqm%3DKBwkwCh7%3DQFJeORGata2ertcJChzh_ezQ%40mail.gmail.com
>>>>>>>>> (
>>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LeSido9jqm%3DKBwkwCh7%3DQFJeORGata2ertcJChzh_ezQ%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 elixir-lang-co...@googlegroups.com.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/b1519f28-ed13-43d1-88a5-64ba6d909e18n%40googlegroups.com
>>>>>>> (
>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/b1519f28-ed13-43d1-88a5-64ba6d909e18n%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 elixir-lang-core+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elixir-lang-core/0d6c0925-4394-43e3-a227-8b43ac10dc3an%40googlegroups.com
>>> (
>>> https://groups.google.com/d/msgid/elixir-lang-core/0d6c0925-4394-43e3-a227-8b43ac10dc3an%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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/ac68901b-2507-4493-9c6d-fc981a2b8241n%40googlegroups.com
> (
> https://groups.google.com/d/msgid/elixir-lang-core/ac68901b-2507-4493-9c6d-fc981a2b8241n%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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/lhq5jocd.7f12c3f4-584d-4ca4-8b44-f945386e1bad%40we.are.superhuman.com.
