Re: Extensions Dependency Checking

On Apr 5, 2011, at 1:42 PM, Aidan Van Dyk wrote:

> Sure, but if you want, the "feature" you can provide can be something like:
> pgtap-1.0 (or any of pgtap-0.2{0,1,2,3,4}).
>
> And if your package is backwards compatable, it could even provide:
> pgtap-0.25
> pgtap-0.24
> pgtap-0.23

I see, I get it.

> And that also means that you don't have to screw every body over when
> some future pgtap-123.45 is no longer compatible, and the extensions
> have relied on "$VERSION > 0.23" meaning they'll work with it.

I see.

> I mean, PG itself is an example. Does pg > 8.4 mean your code will
> work with all future (or even past, but > 8.4) PG versions?

I see. So the extension author can more easily tell users when compatibility has been dropped for something. That makes sense.

> As someone who has had to try and deal with "package versions" for
> dependencies in RPM and DEB, and been through the hell that is open
> source package variants, all with the ability to turn on/off features
> at configure/compile time, a just versions even with <, <=, =, >=, >
> all mapped correctly isn't good enough.

Yeah. The use of an implicit >= in CPAN modules has been a decent 90% solution, but it does cause headaches for people that they can't express things better. The ability to do so would require a mini-language with more operators, precedence, grouping, etc.

> Of course, I'ld love for extension in 9.1 to provide a basic
> provides/features for my extension to give, but if that train has
> already left the station, I don't have much choice ;-(

Yeah, but the way it is doesn't break the ability to do it later. I suspect that Dim and Tom will be thinking about it for 9.2.

Anyway, your post helps me to understand things better, and so I'm less insistent about imposing a version numbering scheme now (though I still think it would be more useful to have one than not).

Best,

David