Automatic dependencies

[Peter Lobsinger]

On Tue, Sep 21, 2010 at 4:34 PM, Paul Wolneykien
<wolneykien at altlinux.org> wrote:
>
>
> 21.09.2010 03:11, NotFound writes:
>>>
>>> * The problem *
>>>
>>>   Extracting a representative set of dependencies using the described
>>> method is only possible when a high-level language compiler that
>>> produces a code of the module translates the set of static module
>>> requirements (i.e. the "import" section entries or "use Module::Name"
>>> expressions) into the corresponding load instructions and places the in
>>> the module initialization section (:init :load), not the "main" module
>>> code.
>>>
>>> * The proposition. Questions *
>>>
>>>  From my point of view, that policy seems logical and natural. Is it
>>> the same for you?
>>
>> No. Just an example: a module should be able to choose what to load
>> during its initialization, depending on environment variables,
>> arguments passed to a initialization sub...
>
>  That is a striking example of a dynamic dependence: if the desired module
> is not found, the error is probably in the program command line or the setup
> of environment variables. In this case, an installation of the program
> itself can still be correct.
>
>>
>>>  Anyway I don't like policies. Instead of that I propose to make some
>>> modifications to the PCT in such a way that any properly defined
>>> compiler would produce a code with all static module loading procedures
>>
>> PCT is just a set of tools. Is not the only way of writing compilers
>> targeting parrot.
>
>  Yes. When a programmer writes such a compiler with no help of special tools
> he/she is responsible for all of the conventions and/or policies to be
> applied.
>
>>
>> Another point of view: this is just a matter of using an appropriate
>> definition. If a module is loaded via PIR directives or during :load /
>> :init phase, is "static" and is a dependency. If not, is dynamically
>> loaded ans should not be considered a dependency.
>>
>
>  Yes again. But that is a little reverse of the problem: if the :load/:init
> phase contains some "dynamic load" code (as you stated above) then the
> resulting set of dependencies is not stable nor static. But I try to find a
> way to encode true static dependencies into the bytecode.
>
>  Information about static dependencies is a very important if you want to
> get a stable software distribution. If one program can not be run without
> another program you should install both of them. In the form of a high-level
> language source code the static dependencies a explicitly stated: if we read
> "use File::Temp;" at the beginning and the program is compiled successfully,
> then there is a good reason to treat the module File/Temp.pm as a static
> dependency.

You've chosen a good example to prove that seemingly-static HLL
dependancies are indeed dynamic. As I understand it, Perl 6 modules
are not tied to the filesystem in such an intuitive way. They may be
name-mangled or managed through a registry of some sort. "use
File::Temp" looks up whatever your system considers to be the default
implementation of File::Temp (there may be different versions by
different authors). This will vary by system, and in fact needs to be
a runtime lookup (if your bytecode is going to be able to be passed
around between systems, robust against reconfiguration, etc).

Perl 6 is indeed a complicated case, but the module lookup functions
for other languages are also not entirely straight forward. Most of
them at least support changing an environment variable to change where
things are looked up. Users could reasonably expect to be able to set
up multiple not necessarily compatible trees of modules using this.
Don't ask me why one would want to do this, but they should be allowed
to.

>  When such a program is translated into a bytecode module the information
> that was explicitly stated is lost: without some policy or convention there
> is no way to distinguish "File/Temp.pm" from a dynamic dependency.
>
>
>  There is still a way to extract the reliable information about static
> dependencies from the original high-level language files, i.e. Perl or
> Python module sources. That approach is in an active use in Sisyphus now.
> Many languages, same problem, different solutions. Why not to unify and
> simplify all of them? One of the Parrot goals is unification, isn't it?
>
> --
> Paul Wolneykien,
>  ALT Linux, Ltd.
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

I think the easiest thing to acheive what you are looking to do (if
I've understood correctly), would be to encode the "static"
dependancies the PBC metadata (you'd probably store that in the
annotations segment or some yet-to-be-devised metadata segment). You
could encourage HLL authors to include this information according to
some sort of convention.

Of course, for the reason described above, I'm not sure you'd be able
to convince them this is worth doing.