[erlang-questions] Erlang package manager

[Tristan Sloughter]

You define it to rely on 5.

rebar3 will then warn you about all other version that are not used.
Assume this app you are talking about is a dep of the project you are
working on and another version of it is chosen because of another dep
depending on it, lets say 6, you then must define at the top level
rebar.config that you want 5 (or 3).

Leaving it up to the user.

--
Tristan Sloughter t@REDACTED



On Tue, Dec 16, 2014, at 11:09 PM, Benoit Chesneau wrote:
>
>
> On Wed, Dec 17, 2014 at 1:18 AM, Tristan Sloughter
> <t@REDACTED> wrote:
>> I'm just throwing my thoughts out there. This isn't to cover all
>>
features I'd want to see in a package manager, but instead just the ones
>>
I know are "controversial". These are also the direction we've gone with
>>
rebar3 (http://rebar3.org).
>>
>>
* Binary packages
>>
>>
Why build from source if you don't need to? Most Erlang applications
>>
have no native code.
>>
>>
* No semver enforcement
>>
>>
I mean, why bother? For one, you can't actually force semantic
>>
versioning. You can require the version be of the format
>>
MAJOR.MINOR.PATCH+[metadata] but not the semantic part.
>>
>>
I think forcing the format in the name of "semver" is confusing and
>>
wrong.
>>
>>
* Strict version declarations
>>
>>
No ">=1.0" or "<1.0 and >0.5". The project should set a version number
>>
of the dependency it relies on.
>>
>>
"Solving" dependencies is a matter of choosing the highest version of a
>>
dep in the dependency tree. This is also followed by maven,
>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
>
>
> What if you want to support a package from version 3 to 5 but not 6
> neither 1 or 2 due breaking changes in the API?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141217/31a955a6/attachment.htm>