Oolite Bulletins

A unique ID would be rather important, yes. Any implementation that doesn’t work if you rename an OXP is broken. Pity we don’t have such IDs for existing OXPs…

But it would get my vote, one hundred percent!

Ahruman wrote:

You’re welcome to implement a dependency system. I suggest “must-load-after” and “should-load-before” keys in requires.plist. The basic logic for this type of dependency management is already implemented in OOOXPVerifier.m.

Does it make sense ever to state load-before? Any kind of sensible dependency management normally only has I depend upon rather than depends upon me. Any patches or whatever should always be loaded after shouldnt they?

Unless maybe you find a broken oxp that has an undeclared dependency, and rather than fix it, you pre-inject a fix? Sounds kind of fishy to me.

Cmdr James wrote:

Ahruman wrote:

You’re welcome to implement a dependency system. I suggest “must-load-after” and “should-load-before” keys in requires.plist. The basic logic for this type of dependency management is already implemented in OOOXPVerifier.m. :-)

Does it make sense ever to state load-before? Any kind of sensible dependency management normally only has I depend upon rather than depends upon me. Any patches or whatever should always be loaded after shouldnt they?

Unless maybe you find a broken oxp that has an undeclared dependency, and rather than fix it, you pre-inject a fix? Sounds kind of fishy to me.

I find that should-be-before adds flexibility without significant complexity. For instance, in the OXP verifier, it’s used by various verifier passes to state that they should be run before the list-unused-files stage, which doesn’t need to know about each stage that provides “used files”. It’s not immediately obvious that there’s a use for it with OXPs, but life would be pretty boring if OXPs could only do things we thought would be useful. :-)

Anyway, the unique-identifier problem is a much bigger issue, and, as I recall, the reason I didn’t implement dependency management last time I thought of it. One way would be to let each ship ID an OXP defines be used as a unique ID – being careful to ensure OXPs don’t end up depending on themselves in this way.

Come to think of it, here’s a usage scenario: A Really Froody OXP.oxp introduces the SuperCoolShip mk. IIII. Bodacious Missions.oxp uses a SuperCoolShip mk. IIII, and includes it in its shipdata.plist. However, the author knows that A Really Froody OXP.oxp may be updated in future to make the SuperCoolShip mk. IIII even froodier. Therefore, Bodacious Missions.oxp declares that it should load before A Really Froody OXP.oxp, so that if both are installed, the canonical extra-froody SuperCoolShip mk. IIII is used if both are installed.

I had to... I just had to... I couldn't hep it.. It was chasing me and it was too fast.

Here it is..

I was going through the OXP List and putting Y's into the working boxes of oxp's I have tested and saw that this was blank. Does it work with 1.76? If so I could Y the box?