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 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+unsubscribe@ googlegroups. com (
> [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/lhpqs0tn.b160ab6b-f0a4-4c58-8d67-c6045a3c7c19%40we.are.superhuman.com.
