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

[Joe Armstrong]

2011/9/13 Frédéric Trottier-Hébert <fred.hebert@REDACTED>:
> Problems I would foresee:
>
> 1. What if I try to include the code that is in charge of fetching code remotely, and that the new one I include is broken. Do I just break the downloads of other files?
>
> 2. What happens if many modules try to include conflicting versions of a dependency? This is a problem already, but managed at a higher level with applications
>
> 3. If my module depends on other local modules (before I've uploaded anything to github) do I add local paths or just none of these clauses?
>
> 4. How would we represent differences between depending on applications and depending on modules? Applications might require drivers, NIFs, etc. which will need specific compiling options.
>
> 5. How does this work for code updates?
>
> 6. What about protocols that are not git, hg, http or whatever and are not known to the VM?
>
> 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.


>The problem is that releases and applications are somewhat an advanced >concept that not all developers know and understand.
>
> --
> Fred Hébert
> http://www.erlang-solutions.com
>
>
>
> On 2011-09-13, at 03:19 AM, Joe Armstrong wrote:
>
>> I had an idea on my way to work ...
>>
>> When you write code, you have *implicit* knowledge of where the
>> external code comes from.
>>
>> When I write the following:
>>
>>     -module(foo).
>>      ...
>>     start() ->
>>          X = lists:reverse(...),
>>          Y = elib1_misc:zap(...)
>>          Z = misultin:request(...)
>>     ...
>>
>> I "know" that lists is part of my local OTP install, elib1_misc is my
>> own library installed
>> in ~/code/elib2_1/ebin and misultin is an imported project stored in
>> ~/imports/misultin
>> I also know that my paths etc are setup so this code will work when I
>> run the program.
>>
>> The problem is the *nobody else* knows this.
>>
>> I could tell the system like this:
>>
>>    -module(foo).
>>
>>    -location(lists,
>> "https://github.com/erlang/otp/blob/dev/lib/stdlib/src/lists.erl").
>>    -location(elib1_misc,
>> "https://github.com/joearms/elib1/blob/master/lib/src/elib1_misc.erl").
>>    -location(misultin,
>> "https://github.com/ostinelli/misultin/blob/master/src/misultin.erl").
>>
>>    ...
>>
>>
>>   The location annotation give a *definitive source" for the module I
>> am using in the module
>>
>>    What could you do with this information?
>>
>>    Answer - a lot - for starters
>>
>>         - automatically check for "latest versions" of libraries
>> download them when they change
>>         - provide "who uses my code" feedback to the authors of the code
>>         - publish (globally) lists of "definitive" versions of code
>>         - recursive track and code dependencies (What do I mean)
>>            when my system discovers that I use misultin - it
>> downloads misultin.erl
>>            misultin.erl will have location dependencies which I can
>> follow, thus the libraries
>>            that misultin calls can be fetched.
>>         - automate code loading
>>
>>    Most often this kind of "additional" information is kept "outside
>> the program" by strictly
>> annotating the program with the location dependencies we bring this
>> information *into* the program
>> in a form where it cannot be detached from the source code.
>>
>>    Comments?
>>
>>   /Joe
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>