Re: on packahing on general and on contents of http://wiki.octave.org/OEP:pkg

[Sergei Steshenko]

----- Original Message -----
> From: Carnë Draug <address@hidden>
> To: Sergei Steshenko <address@hidden>
> Cc: c. <address@hidden>; Rafael Laboissiere <address@hidden>; Ben Abbott 
> <address@hidden>; Jordi Gutiérrez Hermoso <address@hidden>; Juan Pablo 
> Carbajal <address@hidden>; "address@hidden" <address@hidden>
> Sent: Sunday, December 2, 2012 10:32 AM
> Subject: Re: on packahing on general and on contents of 
> http://wiki.octave.org/OEP:pkg
> 
> On 2 December 2012 01:42, Sergei Steshenko <address@hidden> wrote:
>>  Now, say,
>> 
>>  foo_package depends on doo_package
>>  bar_package depends on dah_package
>> 
>>  Where do doo_package and dah_package come from ?
> 
> If doo_package and dah_package are not installed, then from nowhere.
> If they are, the proposal I wrote there suggests the following order:
> 
> - load the latest version availale
> - load the local install of the package
> - load the global install of the package
> - load the package from the external .db, starting from the latest
> added in case there's more than one.
> 
> Carnë
> 


So, this is a _typical_ invitation for trouble. In production environment it 
tooks us onece more than a day to just find out that a wrong version was used.

Search paths are more _evil_ than good.

The decision we made was:

either a thing is taken _exactly_ from the place it is supposed to be, or it is 
not taken at all with a clear error message.

We did sometimes have to use search paths, and in those cases _unconditionally_ 
the search process was logged. I.e. the designers could _exactly_ know which 
versions were taken from where.


The dependency problem I've described can be much more severe - in parenthesis 
I write possible locations as user IDs:

foo1(myself) -> foo2(global, John) -> foo3(global, John, Paul, Mary) -> 
foo4(global, Paul, Mary)

, etc.

So, "scientifically" speaking, one has to define a mechanism of switching 
inheritance (from which user to take) on per dependency tree node basis.

_Or_ to simplify things _drastically_ - just _one_ tree is created on per user 
basis, and then it's the user's responsibility to populate the tree with 
whatever he/she likes. And packages are taken _only_ from user's tree.

The initial tree can be automatically created from global one; user will 
replace stuff in his/her tree as necessary.

The KISS principle.

Regards,
  Sergei.