Hi PAR folks,
First, let me say that I'm sorry for not replying to any of the posts to
the list for the past few weeks. I'm currently behind a proxy that
doesn't allow NNTP to pass through and I'm not actually subscribed to
the mailing list as such. That makes participation a bit of a problem,
but I'm still reading via http://nntp.perl.org.
However, this doesn't mean PAR has been untouched. Quite the contrary:
There have been over a hundred commits since the start of the year and
the (unified, context) diff since the last revision from 2008 amounts to
over 8000 lines.
Most of the development hasn't been in the core PAR distribution but in
the repository extensions. A particularly large fraction of the new code
is in tests. The PAR::Repository and its client now have a respectable
test suite and in the process of writing it, I discovered a plethora of
small and large bugs. Improving the test suite was a necessary precursor
to the necessary refactoring that allowed me to add significant new
features. Specifically, there are two big new features:
PAR::R::Client now fully supports automatic updates from the remote
repository. That means: you specify one or more repository URLs and the
client will automatically download, install, and *upgrade* your packages
on demand. This mostly fixes the number one issue with the use of
PAR::R::Client and even PAR in general: The penalty of loading/unpacking
the PAR files or pp packaged executables (locally or remotely). This is
because the *contents* of the .par's are installed into your perl
libraries. It's as simple as adding the following to the top of your
program[1].
use PAR {
repository => 'https://companyserver.com/bigapp/',
upgrade => 1
};
I put a write-up of some of the more painful technical issues on
use.perl, so if you are interested in some ugly tricks with respect to
hooking into perl's module loading, have a look at
http://use.perl.org/~tsee/journal/38343.
While I fully expect that this completed upgrade support isn't perfect
yet, the other big development is still much less mature but also a lot
more fundamental.
Let's take a step back. Ever since I wrote PAR::Repository::*, people
mistook it for a PAR-based PPM replacement. It was never intended to be
a package manager/installer like PPM but instead as a sort of
application server that could be comfortably and centrally managed,
maintained, and upgraded. Even having separate staging and production
repositories is quite simple as a PAR repository is just a directory on
an ordinary web server or file system. Heck, you can even import one
into git and switch branches as your heart desires. Since the clients
simply fetch the most current packages for their specific needs, they
are always be up to date when launching a new application from the
repository. This envisaged use scenario has been somewhat undermined by
the "auto_install" option that only installs missing (but not updated)
packages. The auto-upgrading as outlined above somewhat reclaims the
original idea of the dumb clients that just use the best that server has
to offer.
After I gave a talk about PAR and the repository concept at YAPC::EU
2008 in Copenhagen, people again asked whether they could use a PAR
repository in place of PPM. I said they couldn't and that the
fundamental difference is that PAR::Repository finds dependencies
dynamically, recursively, at run-time, whenever a module is required as
opposed to PPM's static dependency information. But at the time, I
already had a secret scheme for adding static dependency information to
PAR repositories. Since the work on PAR is done purely in my not so
copious spare time, I didn't spill the beans just yet in case I never
finished it. Seems I was lucky.
Since last night, there are development releases of PAR,
PAR::Repository, and PAR::Repository::Client that sport support for
static dependency extraction from .par files, storage thereof in the
repository, and resolution and application of it in the client!
Getting to this point required a bit of Yak Shaving.
- PAR::Dist's merge_par routine formerly simply copied the first
package's META.yml. Now, it also merges the "provides" as well as the
various requires-like sections.
- The tests of both PAR::Repository and ::Client were in dire need of
improvement because...
- ... both modules needed some refactoring to make way for the rest of
the changes.
- The PAR::Repository aquired a new index file for dependencies.
- The PAR file injection routines use the information from META.yml to
fill it. The removal routines correctly remove the information again.
- To make up for the extra bandwidth required for the dependency
information, a checksum-scheme has been implemented to check for updates.
- The client has a new option "static_dependencies" to enable recursive
resolution of dependencies as found in the new dependencies index.
- The "use PAR {...}" interface now has a "dependencies" option that
enables the client's static dependency processing.
All involved modules have new releases on CPAN[2]. Except PAR::Dist,
they are all developer releases, since there *must* be serious bugs. I
already discovered one in the client and will fix it in the next few days.
Thanks for reading!
Best regards,
Steffen
[1] Currently, there is no way of overriding the default verbosity of
ExtUtils::Install, so whenever a package is installed, there'll be
mention in the console. Furthermore, since (with the simple usage shown
as an example) you're effectively installing into the sitelib of the
running perl, this probably mostly makes sense with a non-system perl.
PAR::Repository::Client *does* offer means of specifying the desired
installation paths. It's just not part of the simple PAR.pm interface.
[2]
http://search.cpan.org/~smueller/PAR-0.985_01/
http://search.cpan.org/~smueller/PAR-Dist-0.44/ (just uploaded)
http://search.cpan.org/~smueller/PAR-Repository-0.18_01/
http://search.cpan.org/~smueller/PAR-Repository-Client-0.23_01/ (a test
still fails, will be fixed asap)
