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 [email protected] 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 <[email protected]>
> 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 [email protected] 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 [email protected] 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 <[email protected]>
>>>>> 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 [email protected]
>>>>>> 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 <
>>>>>>> [email protected]> 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 [email protected].
>>>>>>>>
>>>>>>> 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 [email protected].
>>>>>>
>>>>> 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 [email protected].
>> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/ac68901b-2507-4493-9c6d-fc981a2b8241n%40googlegroups.com.
