Discussion on NewVersionSelection

I didnt want to clutter the main page with questions and discussion, so i created this. Let me (johnkv) know if this not the ideal way. I know there's chat, but a the moment i'm logged in thru vpn on my work laptop and not next to my other computer which has direct-to-internet. This is a wxp pc and i haven't set up cygwin xchat yet.

Anyway...

Comments on Version Selection Files

I'm not sure how the setup listed in "Version Selection Files" in NewVersionSelection satisfies this need:

a build.ves file 5 levels down in the hierarchy imports vN of some_pkg. A top-level version file wants to override what version that build.ves uses, w/o changing that build.ves file.

Another Aspect to Keep

Where is "default" version

With a full-fledged versioning system, then question of where the default version comes from arises. Current proposal says that the "default" version is imported in the file, and the "override" version is in some other version file.

But why this duality? Does it make sense to have all versions in the version file? Or is there value in having the default version one place and the override version another?

How to override

I didnt understand the examples in the voverrides man page, but i think i understand how pkg_ovs works for bridges anyway from reading bridge code.

I think i understand and agree with where you're suggestions are headed.

The .vsel file sounds very much like the params/xyz_ovs.ves that we had locally. They both list version overrides.

In the params/xyz_ovs.ves case, the overrides were applied after a collector had propagated all hier content to the top level. We dont want to do that because of poor cache performance.

We do want to propagate down the overrides to lower levels. I agree that dot is the place.

I'm not sure what you envision would be in dot. It doesnt seem to me like it requires much more than a list of overrides.

SDL code which wants to use the override seems like it could do something like: 

from /vesta/path/ import thingy;
thingy = if .!ovs && ./ovs!thingy then ./ovs/thingy else thingy;

That seems to work and be pretty simple. Ie, a new user could read that code and know what it does.

Of course, we could make that easier: 

thingy = ./generics/apply_ovs(thingy);

Or even, *gasp* 

thingy = ./apply_ovs(thingy);

or, maybe 

thingy = _apply_ovs(thingy);

or what you were suggesting, at the import line 

from /vesta/path/ import_w_ovs thingy

But i have a question. The code above assumes the user of thingy is doing the override. With the import version i guess it's not strictly the user; it's more automatic.

But, i ask, should thingy do its own override:

in thingy pkg a new std file vsel.ves or apply_ovs.ves or something is what import looks for by default, and looks like this: 

import thingy = build.ves;

{
return if .!ovs && ./ovs!thingy then ./ovs/thingy else thingy;
// or
return ./apply_ovs(thingy);
}

Or if we didnt want to change import, ie pure sdl answer, then build.ves could be this 

import thingy = pkg.ves;

{
return if .!ovs && ./ovs!thingy then ./ovs/thingy else thingy;
// or
return ./apply_ovs(thingy);
}

And what we usually put in build.ves we put now in pkg.ves or any other suitably named file.

Non-SDL means not necessarily "Pure Functional"

One tangential concern is about another fundamental principle of vesta -- that the pure functional language of SDL guarantees that a function result (derived file) will depend only on it's arguments, and so thus vesta can see all possible dependencies.

If the versioning system is outside SDL, then that guarantee goes away. I think that's ok, because we're just talking about single bits of data, ie version numbers, with no functions or output<-input relationships -- at least at this point. But if the system were to grow into something more complex, some item might creep in as an un-observed depenency. So i'm just encouraging us to watch for this.