On Jan 4, 2011, at 12:46 AM, Dimitri Fontaine wrote:
> "David E. Wheeler" <david@kineticode.com> writes:
>> Just so long as you're aware that you might get more challenges on this going forward.
>
> Sure, thanks for the reminder. That said I also remember the reaction
> when I used to scan the SHARE/contrib directory to find the extension
> control file having the right name property, and I don't see scanning
> the same directory in order to find out which upgrade file to consider
> depending on several parts of its name as so different.
Silly programmer! You don't have to do that yourself! You can teach the computer to do it for you. It's very good at
thatsort of thing!
> Current code allows you to use the same upgrade script for more than one
> source version, and does so in a way that it's easy to determine which
> upgrade file to seek for.
As Tom pointed out, you can do the same with naming conventions by having scripts \i each other as appropriate.
>> I guess. I'll have to think about how to support it in PGXN, though. And the upgrade keys if they stay in.
>
> Disclaimer: the following is based on my understanding of how you want
> to bundle things, from several discussions we had together at pubs or
> on IRC, please don't read further if you're changed your mind about
> generating the control file from your PGXN YAML specification.
s/YAML/JSON/, and okay. :-)
> Well, I think you're having a dependency inversion problem here. PGXN
> depends on extensions, not the other way round.
What? That makes no sense, so I must be misunderstanding what you're trying to say.
> Also, I really expect
> the extension facility to be mainly used for internal proprietary code,
> mainly procedure collections, and only occasionaly for publishing Open
> Source components.
This is because you're not a Perl programmer. See CPAN.
> So you should be considering the control file as an input to your
> processes, a source file, not something that your service will hide for
> extension authors: there's no benefit that I can see in doing so.
I know, but then you're not a CPAN guy. You're a Debian package guy. It's hardly surprising that we'll have inverted
viewsof this sort of thing. Frankly, I think that you might find StackBuilder a better fit with your world view.
http://pgfoundry.org/projects/stackbuilder/
Best,
David