FAQ
Fellow CPAN-Works:

I've posted a [plan] to implement [PGAN], a CPAN for PostgreSQL extensions. I've tried to closely follow the [CPAN philosophy] to come up with a plan that requires a minimum-work implementation that builds on the existing PostgreSQL tools and the examples of the [CPAN] and [JSAN]. My hope is that it's full of JFDI! I would be very grateful for feedback and suggestions.

[plan]: http://wiki.postgresql.org/wiki/PGAN
[CPAN philosophy]: http://use.perl.org/article.pl?sid=02/11/12/1616209
[CPAN]: http://cpan.org/
[JSAN]: http://www.openjsan.org

Best,

David

Search Discussions

  • Hans Dieter Pearcey at Jan 8, 2010 at 12:37 am

    Excerpts from David E. Wheeler's message of Thu Jan 07 17:36:44 -0500 2010:
    I've posted a [plan] to implement [PGAN], a CPAN for PostgreSQL extensions.
    I've tried to closely follow the [CPAN philosophy] to come up with a plan that
    requires a minimum-work implementation that builds on the existing PostgreSQL
    tools and the examples of the [CPAN] and [JSAN]. My hope is that it's full of
    JFDI! I would be very grateful for feedback and suggestions.
    Perl's toolchain went through a lot of growing pains in order to let
    distributions control their own installation process (./Build) rather than
    invoking an external binary (make).

    You may want to sidestep some of this pain from the beginning by having the
    install process always run something from . instead of depending on make. e.g.

    ./build
    ./install
    ./installcheck

    Maybe your client can even assume make && make install && make installcheck if
    any of those executables aren't present, but being able to override them easily
    is a huge win for future extensibility.

    Even if make is currently the standard, well, that was true of EUMM too; have
    you ever tried to extend it?

    I've never written a postgres extension, obviously, so all of the above may not
    be relevant.

    hdp.
  • David E. Wheeler at Jan 8, 2010 at 12:43 am

    On Jan 7, 2010, at 4:36 PM, Hans Dieter Pearcey wrote:

    Perl's toolchain went through a lot of growing pains in order to let
    distributions control their own installation process (./Build) rather than
    invoking an external binary (make).

    You may want to sidestep some of this pain from the beginning by having the
    install process always run something from . instead of depending on make. e.g.

    ./build
    ./install
    ./installcheck

    Maybe your client can even assume make && make install && make installcheck if
    any of those executables aren't present, but being able to override them easily
    is a huge win for future extensibility.

    Even if make is currently the standard, well, that was true of EUMM too; have
    you ever tried to extend it?

    I've never written a postgres extension, obviously, so all of the above may not
    be relevant.
    Yes, if there wasn't already significant investment in `make` for PostgreSQL, I'd be looking into something else. AS it is, though, that's what the project already supports (via a whole slew of useful targets included in PGXS), and so that's what the PGAN client will use. If PostgreSQL core ever comes up with some other standard for installing extensions, PGAN client will be updated to support it. But writing the installer itself is not what PGAN is about at all.

    And yes, I have extended a Makefile, for [pgTAP](http://github.com/theory/pgtap/blob/master/Makefile). It was painful for someone who knows nothing about `make`, but it works well enough.

    Best,

    David
  • Hans Dieter Pearcey at Jan 8, 2010 at 1:08 am

    Excerpts from David E. Wheeler's message of Thu Jan 07 19:43:25 -0500 2010:
    Yes, if there wasn't already significant investment in `make` for PostgreSQL,
    I'd be looking into something else.
    Sorry, I think you've misunderstood. I wasn't suggesting that you use
    something else, or write a new installer, or whatever.

    I was suggesting that you have a level of indirection between the PGAN client
    and make so that it's easy to support both the current standard installer
    (make) and whatever else might come in the future.

    If your client always runs

    make
    make install
    make installcheck

    then you are *stuck* using make and good luck shoehorning anything else in
    there.

    If your client looks for

    ./build
    ./install
    ./installcheck
    # or whatever, don't be fussed about the names

    then you can use make now and trivially use, you know, Korn shell or whatever
    when the postgres community goes nuts and switches en masse.
    And yes, I have extended a Makefile, for
    [pgTAP](http://github.com/theory/pgtap/blob/master/Makefile). It was painful
    for someone who knows nothing about `make`, but it works well enough.
    Writing make is pretty easy. Writing something that writes make and shell and
    whatever else is less so; that's what I was referring to.

    hdp.
  • David E. Wheeler at Jan 8, 2010 at 1:12 am

    On Jan 7, 2010, at 5:07 PM, Hans Dieter Pearcey wrote:

    I was suggesting that you have a level of indirection between the PGAN client
    and make so that it's easy to support both the current standard installer
    (make) and whatever else might come in the future.
    Oh, yeah, of course. Since I fully expect PostgreSQL to develop something in this department, it will be pluggable. What will come after make I don't know, but I expect it to change and will still want to support old stuff when it does.
    Writing make is pretty easy. Writing something that writes make and shell and
    whatever else is less so; that's what I was referring to.
    Yeah, I want no part of that. ;-)

    Best,

    David
  • David Golden at Jan 8, 2010 at 4:38 am

    On Thu, Jan 7, 2010 at 5:36 PM, David E. Wheeler wrote:
    My hope is that it's full of JFDI! I would be very grateful for feedback and suggestions.
    Thoughts in no particular order:

    * Limiting to gzip/bzip2 tarballs may screw over Windows users who
    don't have access to a portable extraction program. (CPAN also
    supports .zip files.) Perl papers over these cracks with Perl
    (Archive::*), but PGAN won't have that as an option.

    * META spec -- don't get too wedded to the CPAN spec until we finish
    2.0 and you decide if you still like it.

    * I don't see how a Makefile can be optional if you need it to build extensions

    * Don't be specific about update frequency for a search site.
    "Updated as often as is practical" or something vague like that. (If
    you implement Andreas fast mirroring system, you can update within
    minutes!)

    * PGAN client -- decide if you want to have command arguments like
    apt-get (e.g. "pgan install Foo") or whether you want to be like cpan
    without them (e.g. "cpan Foo"); most OS installers seem to use
    'install' so either choose that or make your client smart enough to
    DWIM

    * Define a "minimum API" between pgan and make, including arguments
    that all Makefiles must support. You want to avoid the soup of
    arguments that EU::MM and M::B have built up. Do you need "make
    installdeps"? Do you need an equivalent to INSTALL_BASE? Standardize
    these now.

    * Create a common configuration file with sections for different
    things like mirrors, commands, etc. Have a 'pgan' section for things
    that are specific to that particular client only. That way, when
    someone writes pganplus, it can us the same common configurations

    [Ed. note: If CT2.0 migration happens on schedule, a common CPAN/PLUS
    config system may be my QA hackathon project.]

    -- David
  • David E. Wheeler at Jan 8, 2010 at 4:47 am

    On Jan 7, 2010, at 8:38 PM, David Golden wrote:

    Thoughts in no particular order:
    Thanks for these, David.
    * Limiting to gzip/bzip2 tarballs may screw over Windows users who
    don't have access to a portable extraction program. (CPAN also
    supports .zip files.) Perl papers over these cracks with Perl
    (Archive::*), but PGAN won't have that as an option.
    Good point. I'll probably require Archive::* to start with in the PGAN client. But implementation aside, I can add a note about .zip.
    * META spec -- don't get too wedded to the CPAN spec until we finish
    2.0 and you decide if you still like it.
    So far so good. I don't expect to get to the client until after 2.0 is finished anyway.
    * I don't see how a Makefile can be optional if you need it to build extensions
    Hrm. Well you can upload scripts to CPAN. Did you know that? CPAN.pm doesn't know what to do with them, but they're there. I was just trying to keep things as open as possible. Might end up requiring it anyway, for the reasons you cite.
    * Don't be specific about update frequency for a search site.
    "Updated as often as is practical" or something vague like that. (If
    you implement Andreas fast mirroring system, you can update within
    minutes!)
    Will have to check that out. I plan to steal everything I can can from PAUSE, CPAN, CPAN.pm, CPANPLUS, and JSAN::Client.
    * PGAN client -- decide if you want to have command arguments like
    apt-get (e.g. "pgan install Foo") or whether you want to be like cpan
    without them (e.g. "cpan Foo"); most OS installers seem to use
    'install' so either choose that or make your client smart enough to
    DWIM
    Yeah, should be easy.
    * Define a "minimum API" between pgan and make, including arguments
    that all Makefiles must support. You want to avoid the soup of
    arguments that EU::MM and M::B have built up. Do you need "make
    installdeps"? Do you need an equivalent to INSTALL_BASE? Standardize
    these now.
    I'm not doing that part. I'm relying completely on PGXS, which is the Makefile included in PostgreSQL builds (postgresql-devel packages), to supply all that stuff. I don't want to go near the actual build system. Way too many bikeshed colors there and not my area of expertise in the slightest.
    * Create a common configuration file with sections for different
    things like mirrors, commands, etc. Have a 'pgan' section for things
    that are specific to that particular client only. That way, when
    someone writes pganplus, it can us the same common configurations
    Good call.
    [Ed. note: If CT2.0 migration happens on schedule, a common CPAN/PLUS
    config system may be my QA hackathon project.]
    I'll be at OSCON for sure!

    Best,

    David
  • David Golden at Jan 8, 2010 at 5:06 am

    On Thu, Jan 7, 2010 at 11:47 PM, David E. Wheeler wrote:
    * I don't see how a Makefile can be optional if you need it to build extensions
    Hrm. Well you can upload scripts to CPAN. Did you know that? CPAN.pm doesn't know what to do with them, but they're there. I was just trying to keep things as open as possible. Might end up requiring it anyway, for the reasons you cite.
    If CPAN required an Makefile.PL/Build.PL, then the clients would know
    what do with scripts (i.e. install them!). There are raw .pm files on
    CPAN, too. CPAN.pm generates a Makefile.PL for those.
    Will have to check that out. I plan to steal everything I can can from PAUSE, CPAN, CPAN.pm, CPANPLUS, and JSAN::Client.
    See File::Rsync::Mirror::Recent
    * Define a "minimum API" between pgan and make, including arguments
    that all Makefiles must support.  You want to avoid the soup of
    arguments that EU::MM and M::B have built up.  Do you need "make
    installdeps"?  Do you need an equivalent to INSTALL_BASE?  Standardize
    these now.
    I'm not doing that part. I'm relying completely on PGXS, which is the Makefile included in PostgreSQL builds (postgresql-devel packages), to supply all that stuff. I don't want to go near the actual build system. Way too many bikeshed colors there and not my area of expertise in the slightest.
    Yes, but you're talking about various PGXS extensions people might
    add. I'm saying that you should be explicit about what is supported
    and what not. (E.g. the pgan client will support PGXS version X.YZ)
    [Ed. note: If CT2.0 migration happens on schedule, a common CPAN/PLUS
    config system may be my QA hackathon project.]
    I'll be at OSCON for sure!
    I may try to go this year as I've never been and some of the CPAN and
    CPAN Testers developments would be fun to talk about.

    David
  • David E. Wheeler at Jan 8, 2010 at 5:29 am

    On Jan 7, 2010, at 9:06 PM, David Golden wrote:

    If CPAN required an Makefile.PL/Build.PL, then the clients would know
    what do with scripts (i.e. install them!). There are raw .pm files on
    CPAN, too. CPAN.pm generates a Makefile.PL for those.
    Yeah, crazy, eh? Maybe I will require a Makefile just because it's easier for the toolchain.
    Will have to check that out. I plan to steal everything I can can from PAUSE, CPAN, CPAN.pm, CPANPLUS, and JSAN::Client.
    See File::Rsync::Mirror::Recent
    Interesting. I especially like the "!!!! PRE-ALPHA ALERT !!!!".
    Yes, but you're talking about various PGXS extensions people might
    add. I'm saying that you should be explicit about what is supported
    and what not. (E.g. the pgan client will support PGXS version X.YZ)
    Oh, yes. It will support whatever is in PostgreSQL 8.0+ most likely. Maybe 8.1.
    [Ed. note: If CT2.0 migration happens on schedule, a common CPAN/PLUS
    config system may be my QA hackathon project.]
    I'll be at OSCON for sure!
    I may try to go this year as I've never been and some of the CPAN and
    CPAN Testers developments would be fun to talk about.
    Yeah, it's a good show, a kind of annual reunion. You should come!

    Best,

    David
  • David Golden at Jan 8, 2010 at 5:33 am

    On Fri, Jan 8, 2010 at 12:29 AM, David E. Wheeler wrote:
    See File::Rsync::Mirror::Recent
    Interesting. I especially like the "!!!! PRE-ALPHA ALERT !!!!".
    Yeah... well, it's a memory hog, but cpan.hexten.net,
    cpan.cpantesters.org and cpan.dagolden.com are running it at least.
    Some of those for months.
    I may try to go this year as I've never been and some of the CPAN and
    CPAN Testers developments would be fun to talk about.
    Yeah, it's a good show, a kind of annual reunion. You should come!
    It's not cheap and I don't get company support. But if I can get a
    talk accepted, that might make the difference.

    David
  • Ask Bjørn Hansen at Jan 8, 2010 at 6:04 pm

    On Jan 7, 2010, at 21:29, David E. Wheeler wrote:

    See File::Rsync::Mirror::Recent
    Interesting. I especially like the "!!!! PRE-ALPHA ALERT !!!!".
    www.cpan.org and the search.cpan.org mirrors are all using it, too (some of them indirectly, but still).


    - ask

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedJan 7, '10 at 10:36p
activeJan 8, '10 at 6:04p
posts11
users4
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase