But also I think we should remove the `module` part from the proposed behavior.
That’s the point I’m making, it’s not flexible as you’ve pointed out. But the
features-> deps part must be static and simple.
On Tue, May 16 2023 at 6:52 AM, Zach Daniel < zachary.s.dan...@gmail.com >
wrote:
>
> 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/lhq5nh45.2d3ff6c2-371a-4d74-bbe5-3ef6b3d5b9d7%40we.are.superhuman.com.
