[erlang-questions] where did my code come from?

[Frédéric Trottier-Hébert]

On 2011-09-13, at 07:25 AM, Joe Armstrong wrote:

> 2011/9/13 Frédéric Trottier-Hébert <fred.hebert@REDACTED>:
>> Problems I would foresee:
>> 
>> ...
>> 
>> In my opinion, the basic code-sharing block should be the OTP application (or OTP library application), a bit similar to what Rebar and Agner are using at the moment. All these dependencies can be somewhat described as part of the '.app' file of each application you write, and likely are already described in there for whatever build tool to be used. The problem is that OTP has no way to react to these dependencies as of now, although it can check for conflicts, registered names, etc.
>> 
>> Related to the list above, it would be simpler to handle point 1 (stuff can still be built, but not assembled into a release, or dependencies will be missing at startup), point 2 (versions are handled as part of releases, but still not optimal), point 3 (the {modules, ...} tuple does this). Point 3 would have no clear way to do it, no obvious fallback. Point 4 is only handled by tools like rebar or agner, that will try to compile them for you; Agner takes a command given by the developer to tell you how to build the code. Point 5 works with appups and relups and dependencies -- very hard to do, still. No fix possible for point 6 that I can think of.
>> 
>> It would be somewhat simpler and safer, I think, to build the mechanism on top of OTP apps rather than raw modules.
> 
> I'm not sure about this - often (very often) modules escape from their
> context - so for example, individual modules in one application
> escape from that application and find themselves being included in other
> applications. This is just done by googling and cut-and-paste. I do
> this frequently. How do I solve X? - Google a bit. I find some code in
> yaws
> or mochiweb that does what I want. I just take the individual module
> remove it from its context and either use it or modify it. The changes
> I make are not back-propagated into the original module. If you
> keep the meta data in the module itself it won't get lost if the module
> is seen "in the wild" - if you put the information outside the module
> then one day you will loose it.
> 

For individual modules escaping their original context, this is something that can be handled with Reltool using filters, although it's not fully optimal or easy to do. I've had this in some code where I depended on mochiweb modules, but not the whole thing. 

In my case, my release config file (https://bitbucket.org/ferd/blogerl/src/e8317b92af3a/rel/rel.conf) has this policy for mochiweb:

   {app, mochiweb, [{incl_app_filters, [
                      "^ebin/mochiutf8.beam$",
                      "^ebin/mochiweb_charref.beam$",
                      "^ebin/mochiweb_html.beam$"
                     ]},
                     {incl_cond, include}]}

While in the release in general applications are not included by default ({incl_cond, exclude}). This lets me build a specific mochiweb library for my release, only containing the 3 files mentioned there.

By doing so and depending on mochiweb in rebar (or agner, or any other build system), I'm able to create a final application with only the files I need, but the source version can still be kept up to date with all the related libraries. The problem here is how accessible this way of doing things is to Erlang programmers. Most of us do not know how to build releases with a lot of ease.

In any case, this doesn't solve the other issue you mentioned -- if I modify the mochiweb modules, then I need to fork it, make a branch or copy the repository myself and then link to that in rebar/agner/whatever, hoping that the online repo will contain all the information I need. There will be no quick way to relate *my* mochiweb to the *original* mochiweb unless someone checks the link and sees that github, bitbucket or google code has some link relating it back to the original version.