Considering releases, we would probably need to generate a static artifact
to let us know what features were enabled when it was compiled without
running the app. It is helpful when things go wrong in production.
Also, would this feature be something that Erlang itself could benefit
from? OTP and Elixir teams could introduce "Release Channels Feature
Flags," where people could opt-in to test things ahead of time without
committing to a feature per se.
On Tuesday, May 16, 2023 at 6:54:02 AM UTC-4 zachary....@gmail.com wrote:
> 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....@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...@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-co...@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-co...@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/16e87613-3c03-4d4a-968f-5ee02a75d940n%40googlegroups.com.
