Okay, I think the API sync issue is fixed; omnipitr v0.3.1 now shows up on the site. http://www.pgxn.org/dist/omnipitr/ #phew

here seem to be some issues with the API syncing; will get them fixed today. Sorry for the lack up site updates in the meantime.

Day before yesterday, I finally got all of PGXN moved to a new server. I had been using a small server owned by my company, Kineticode, and hosted by Command Prompt. That was fine for a while, but CMD was needing its rack space back, and what with my new job, I was shutting down Kineticode, too. It was time to move PGXN elsewhere.

For a while, I got a lot of support and assistance towards moving PGXN to a PostgreSQL community server. Dave, Magnus, and Stefan kindly spun up a VM for me, and gave me permission to install Perl modules from CPAN, provided I supply them with a script to report to Nagios when Perl modules were out of date, which of course I did. This was necessary because I built PGXN with some pretty recent versions of CPAN modules that are not yet available in Debian stable. I was looking forward to getting things running and integrating with the community authentication service.

I got the server built, and everything was working reasonably well. Magnus and I were just working out some issues with the proxy server configuration, and I was starting to think about how to migrate the data over. But first, I decided to refactor the Perl module script to use a more efficient implementation. I fired it off and piped its output to the cpan utility to just get everything updated. Unfortunately, unlike my first implementation, which reported only on CPAN-installed modules, this version of the script also reported when Debian-installed modules were out-of-date. And since I have my CPAN build configuration set up to remove previous installations, I upgraded all those modules, replacing them with new versions.

Well, this was a major fuckup on my part. Turns out there’s no simple way to restore Debian-distributed versions of the modules without rebuilding the entire system. Worse, this was exactly the sort of thing the community sysadmins feared. They have to maintain a lot of servers. So they naturally prefer that they all be as similar as possible. The new PGXN server had been mostly similar to what they had before, and Dave and company had been willing to compromise quite a bit to get PGXN going, but I, unfortunately, demonstrated how easy it is to ruin the whole thing.

So we decided that a community server isn’t the right place for PGXN. At least not yet. Perhaps in a year or two the Debian distribution will be updated to have all the prerequisites I need. Better yet, maybe someone create a PGXN debian distribution! (Volunteers welcomed.) Then I won’t have to do anything special and we can try again (without any sudo privileges for me!). But in the meantime, I still needed to move things.

Fortunately, depesz came to the rescue. He has a very nice box hosting his blog, explain.depesz.com, and a few other things, and would I like to set things up there? Depesz used perlbrew to set up a Perl install just for the PGXN system accounts, meaning I could install any Perl modules I needed without interfering with the system Perl. And each account has its own privileges to run the services it needs (Manager, API, Site) without the risk of breaking anything else. A few days after getting access, we had everything set up and ready to go. I pulled the trigger on Monday, and it went of without a hitch.

My thanks to depesz for the server and all the assistance, not to mention his donation! PGXN now has a very nice home where it can mature.

And as for the future, I have some thoughts about that, too.

• I’d like to blog about the migration itself, and how easy it is (and isn’t) to build PGXN.
• There are some bugs to be fixed and minor improvements to be had. Interested in helping out?
• I’d love to hear your ideas about how to improve PGXN. What would make it better? What doesn’t work quite right for you now?

And yes, now that this migration is finally done, I expect I’ll have more time to blog and work on PGXN going foward. Please leave your thoughts and ideas in the comments. This thing is wide open to any kind of idea, and I would greatly appreciate your feedback.

Many thanks to depesz for the new PGXN hosting! http://depesz.com/

PGXN Manager will be back up as soon as your DNS records update. All the PGXN sites are on their new server.

manager.pgxn.org will be doing down for the move to the new server in 10 minutes. #WishMeLuck

PGXN Manager will be going down for the move to the new server this evening. Stay tuned for details!

Anyone interested in building RPMs and/or Debian packages for the various parts of the PGXN infrastruture?

New server fell through, unfortunately. Will be looking for a new home for PGXN this week.

By Daniele Varrazzo

Finally, here it is. Well tested, documented, and pampered. With the PGXN Client installing extensions from the PGXN Network is a breeze:

$ pgxn install semver
$ pgxn load semver
$ psql
=# select 'foo'::semver;
ERROR:  bad semver value 'foo': expected number at foo
LINE 1: select 'foo'::semver;

Error! Meaning: success!

The number of extensions on PGXN is steadily increasing, so we hope the client will make their adoption even easier.

The client is now extensible: either writing in Python to reuse some of the other commands implementation or writing new self-contained scripts in any language to be invoked by the pgxn commands dispatcher. The first client extensions are already available: PGXN Utils and PGXN:Meta:Validator are targeted for easier development of new extensions.

The client is released on PyPI, so installing is just:

$ sudo easy_install pgxnclient

Complete documentation and further links are available from the project homepage.

Any feedback is welcome; you can contact me and all the other people behind PGXN on the PGXN User Group. See you there!