Sorry for late reply,
Steven: As Tim pointed out, that means an OTP level change.
The distinction i was making was is that there are two different tasks to solve:
- Having a way to fetch dependencies (we have rebar, ERL_LIBS, ...),
- Having a way to do some action (compile, test, run, ...) with the
correct dependencies.
I don't think there is much need for version constraints in
applications _before_ there is multi-version support in the tools we
use.
However storing information on how to build an application (compiler
opts, dependencies, OTP requirements) in the .app would be a step in
the right direction - that is something for a different thread though.
Olav
2013/5/31 Tim Watson <watson.timothy@REDACTED>:
> Hi Steve,
>> On 30 May 2013, at 00:29, Steve Davis wrote:
>> However, it seems to me that ERL_LIBS works pretty good for me... except where we have "deps" on particular versions.
>>>> Yeah, that's the problem with ERL_LIBS - otherwise, it works great.
>>> I'm throwing it out that if our apps were reliably semantically versioned (www.semver.org) and that the .app file were updated to recognize versions in
>> {application, _, {applications, [...]}}
>> That's an OTP level change though right? I think the Olav was trying to address some of the issues around dependency handling without assuming changes to core Erlang/OTP or rebar.
>>>>> ...where atom was "latest" and {atom, version} were some .ez or other ERL_LIBS folder...
>>>> ...would that not solve a whole raft of the issues here?
>>>> Interested in the responses :)
>>>> Possibly it might help for some tools, but rebar doesn't use the application file currently. Even if you did get this feature into OTP, such that the code loader recognised the versions of things you're attempting to work with specifically, you wouldn't get around all the issues. What about applications where dependencies share dependencies on different major versions, i.e., you need rabbitmq-client + webmachine + mochiweb2 but also raik + webmachine + mochiweb 3 or whatever? How do you pick the right one to download, to compiler, to use? And what about dependencies that aren't packaged so that rebar can build them? Do you fork those repositories and maintain rebar support all yourself? What about needing to build multiple times against, say, multiple versions of OTP for testing. What about when a dependency has native code that needs to be built and you need to ensure that it is built for the same arch/platform as the emulator it's getting loaded into, assuming you've got mu
> ltiple OTP installs? And so on...
>> Some of the things I wrote in that blog post (that Olav references in his project's README) were intended to address, or at least think about, those kinds of issues. I've since moved back to plain old rebar, with a few plugins to customise the dependency handling, since I had neither the time nor the appetite to try and solve all the various problems. Now I'm left with annoyances, but nothing that prevents me from getting stuff done. I wish Olav the best of luck with his tool though, and will be keeping a close eye on it.
>> Cheers,
> Tim
>> _______________________________________________
> erlang-questions mailing list
>erlang-questions@REDACTED>http://erlang.org/mailman/listinfo/erlang-questions
--
Med Vennlig Hilsen
Olav Frengstad
Systemutvikler // FWT
+47 920 42 090