Quick Status Update

2026-10-07T16:13:48Z

Sometimes I wish I weren’t such a perfectionist.

But not often.

A quick update:

So far, I’ve spent 43 hours on the PGXN Manager database. I had estimated 24 hours. Ha ha ha ha ha!

I’ve spent 45 hours on the implementation of the app itself. I had estimated 40 hours.

How will I make up the difference? I’m not sure, really. I’ve already under-recorded my hours quite a lot, basically donating my time to create SemVer and to create the basic HTML layout for the site (I suck at design, but found a good template to base it on). That will likely continue. This is an OSS project, and while I’m getting paid to work on it thanks to our generous contributors, I’m also contributing quite a lot of time to it.

Speaking of contributors, we’ve still not quite met our fundraising goals. There’s enough there for me to finish PGXN Manager so that you can start releasing your extensions on PGXN, and for me to start on the search and documentation site, but not finish it. If you know any organizations that would like to sponsor this work and get their name and link on the PGXN site in perpetuity, please send them over!.

Ahem.

So what have I been doing? I’ll write up some notes in a few other blog posts, including how I’m generating JSON in the database, using Plack for the app, and nicely-degrading Ajaxification with jQuery and RESTful URLs (I hope!). The main page of the app works, as does authentication via basic auth. There’s a screen to request a user account, and a UI for PGXN admins to accept or reject such requests. To make it actually usable, I just need to add the upload feature for users, and then I can do a first release. That will allow people to sign up, get approved, and start uploading extensions for distribution on PGXN.

I will get that that done this week.

After that, I’ll add screens for users to edit their account information, change passwords, reset passwords, and edit permissions. I expect each of those to take less time, as they’ll use a lot of the infrastructure I’ve already built.

Watch this space, and thanks for your patience!

Oh, and if you want to help out, please do fork PGXN::Manager and ping me in #pgxn on Freenode for the deets on getting it built.

Status Update: DB API, Extension Versions RFC

2026-10-07T16:13:48Z

I spent most of the time I had to work on PGXN the last two weeks creating the database for PGXN Manager. I had estimated 24 hours of work to design the database. So far I’ve logged 34 hours. But I think that will come out in the wash, really, because I did a lot of work to generate JSON from database functions. This is code I had originally expected to do in the app layer. I’m starting work on that this week, with an estimated 40 hours. Hope I can do it in 30. :-)

I’m pretty happy with how the database API is turning out. See the nifty database API documentation I whipped up using gendoc and embedded MultiMarkdown. There are still a few tweaks I need to make. I just checked in a change to eliminate all the ALIASes I blogged about last week. Turns out that one can just function-name-qualify the function parameter names. Who knew? I sure didn’t.

But I do have a question for you, dear readers. Right now, the database requires that extensions have unique version numbers in every distribution. So if, for example, you uploaded the distribution foo 1.2.2 with the extension bar 1.2.2, when you next uploaded foo 1.2.3, bar could not be 1.2.2. I designed this this way by following my own practice of always incrementing the version numbers of all modules included in my CPAN distributions. So all modules have unique version numbers, with never a duplicate.

However, CPAN itself only cares that distributions have unique version numbers. It doesn’t care about the version numbers of included modules. See, for example, HTML::Mason. Note that the various included modules have all sorts of different version numbers, and many have no version numbers at all. So while the core module has a version number (1.45 at the time of this writing), if you click to look at older versions, say Mason 1.44, you’ll see that no other modules have their version numbers changed.

I don’t think I want to allow extensions without version numbers on PGXN. That’s been a recipe for many annoyances with CPAN. But maybe I should allow extension version numbers to repeat? The upside is less maintenance for multi-extension distribution authors. The downside is potentially less accuracy in the determination of prerequisites.

For example, say that we have two versions of distribution foo:

----------------------------------------------------------------------------- Distribution Extensions -------------------------------------- -------------------------------------- foo 1.2.2 foo 1.2.2\ bar 1.2.2 foo 1.2.3 foo 1.2.3 bar 1.2.2

Note how the version number of extension bar has not changed between releases. But if I was a user of both foo and bar, and I specified that I required bar 1.2.2 but was actually using stuff in foo 1.2.3, I could end up with errors because I would only have foo 1.2.3.

This is an issue periodically faced by Perl hackers. I might require HTML::Mason::ApacheHandler 1.69 but really what I need is HTML::Mason 1.44. Of course, as a Perl hacker, it’s my responsibility to make sure I require exactly what I need, but sometimes it’s not clear what’s the primary module in a distribution. And if I don’t realize that the version number of HTML::Mason::ApacheHandler doesn’t change with every release, I might make mistakes.

Maybe that’s okay. Maybe PGXN should be less rigid like this. But I’m leaning toward keeping things as they are and requiring new versions of every extension in every upload of a distribution. It’s a bit tougher for those (few?) hackers who will create multi-extension distributions, but probably more reliable for everyone else.

What do you think?

Anyway, I’m getting to work on the Web app this week while this issue percolates. Been studying up on Plack. So nice!