<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On 6 Mar 2012, at 14:42, Anders Nygren wrote:</div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Tue, Mar 6, 2012 at 8:03 AM, Kenneth Lundin <<a href="mailto:kenneth.lundin@gmail.com">kenneth.lundin@gmail.com</a>> wrote:<br><blockquote type="cite">What I meant was that I am not convinced that it is necessary and very<br></blockquote><blockquote type="cite">useful to have the include files<br></blockquote><blockquote type="cite">inside an archive (while using them).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">But it might be possible to convince me :)<br></blockquote><br><br>Yaws and gettext requires some .hrl files for compiling dynamic pages.<br>I think there may be other cases where code is compiled during runtime<br>where it is useful to have access to the .hrl files.<br><br>/Anders<br><font class="Apple-style-span" color="#006312"><br></font></div></blockquote><br></div><div>In general, I think .ez archives are an ideal unit of packaging and distribution (as dependencies) and therefore making them fully self contained is very helpful. If you specify 'lager >= 1.0.2' as a dependency and all I have to do is find and fetch the archive (and check the MD5 and whatnot) then stick it somewhere useful on the machine, the subsequent build (handling of dependent packages), release assembly and other things just work really nicely. Having to 'manually' pull the includes out before being able to utilise the archive as a compile time dependency is just a bit annoying for tools authors that's all. </div><div><br></div><div>From what Ulf and Anders have mentioned, it sounds like there are other use cases too. Some other thoughts: If you want to be able to bundle an executable archive, are you at the point where you are going to want to bundle multiple applications in it (like it was a release) perhaps? This is certainly how bundled escripts seem to work (in terms of having lots of modules in them) although admittedly the 'application' concept doesn't really exist within those any more.</div><div><br></div><div>Also, there is a 'where_is_file' function in the code module, which is quite useful for things that are in 'known' places. What would be a lovely increment beyond that, would be a way to resolve a resource path within a 'known' place inside an archive (such as an application's priv dir and so on) to a binary without having to unpack the whole archive. For loading templates and config files and the like, not having to unpack is really useful and this feels like the kind of thing you'd want to have done properly in one place, rather than lots of people implementing different mechanisms to do the same thing. Sure this isn't completely essential, but it's the kind of thing that avoids 'fiddling around' with the packages post installation and makes the feature more useful and accessible to developers - much like Java's ClassLoader.getClassPathResource(String) or .NET's equivalent. </div><div><br></div><div>I do realise that loading shared libraries from inside of archives isn't feasible though, so there are obviously some cases where you've got to extract at least part of the contents onto the file system. </div><br><div>Cheers,</div><div><br></div><div>Tim</div></body></html>