Hi Paul,
Paul Fenwick wrote:
> I'm giving a talk on all the awesome things people have missed in Perl at
> the upcoming Linux.conf.au in Tasmania, Australia[1]. Included in this list
> is PAR. While I've been using PAR to build stand-alone executables and .par
> files for a while now, I'd like to be able to showcase some of the more
> advanced features.
That's awesome!
> I've got some specific questions with things I've been toying with, but
> before I ask them, I want to note that any sort of input on what I should be
> showcasing here is appreciated. If there's something cool that can be done
> with PAR, then feel free to mention it, and I'll see if I can get it into my
> talk[2].
Maybe a plugin system such as Padre's? It doesn't support repositories
of plugins and remote installation yet, but most of the infrastructure
for that is there (as you know, see below). What's so cool about the
existing system? You can simply drop a .par file in your .padre/plugins
directory and it will automatically be picked up. You can also download
one of the plugin distributions from CPAN and instead of installing it
into the system, you can try the plugin first via "make installplugin"
and it automagically puts it in your .padre directory for you.
Another thing that comes to mind (apart from repositories) is covering
one of the more advanced methods of creating .par files automatically
from CPAN modules.
> Recently I've been toying with the idea of remote repositories. I had a
> PAR-using friend comment to me recently that they got in a bit of a knot,
> with different users and machines having different versions of their .par
> files, which made things more complex than they'd like.
I've been there, too. And my solution was:
> It struck me that remote repositories could solve this sort of problem. One
> could simply distribute minimal code that will automatically fetch the
> desired application, supporting modules, and upgrades where appropriate:
>
> use PAR { repository => 'http://my.example.com/', upgrade => 1 }
>
> # We can now run our application based purely on code loaded
> # from our remote repository...
>
> My::App->run();
>
> Due to time constraints, I haven't actually tried the code above, and
> there's one thing in particular I wanted to check before I did.
You're missing a "use My::App;" there, at least.
> Is the 'upgrade' option actually respected when used in the form described
> above? I know that I can use 'install => 1' to install .par files form the
> repository, but I'd like them to be upgraded when they change.
>
> From my examination of the code (PAR::_import_repository) I *can* see the
> install option being passed to PAR::Repository::Client (as auto_install),
> but there seems to be no passing of the upgrade option[3].
>
> Is there some magic way that the upgrade option is being passed? Is this
> working as intended?, or is this an unimplemented feature?
It's been two years since I worked on it. I still remember that the
upgrading is *not* finished. I didn't have enough time and exams were
nudging closer with every hour I spent on programming.
Since, I didn't get much feedback on the upgrading feature of
PAR::Repository::Client, so I never got back to finishing it. You could
always have a simple stand-alone upgrade manager which uses
PAR::Repository::Client to install the newest versions of the module
from the remote repository. But naturally, it's not the main idea of the
module and you'd also need a static list of packages to track.
This reminds me of another (big) feature I was asked to implement more
times than I care to remember: PAR::Repository does not maintain
dependency information. That's dynamically determined in the client when
a given namespaces is required. That's all great and well for the use
case you outlined, but people seem to want to use PAR::Repositories as
PPM repository replacements and that requires static dependency
information. I've done some small steps in that direction, but the work
left seems still a bit herculean for my taste.
> Finally, when using PAR::Repository::Client (or theoretically the upgrade
> option to PAR), is it possible to provide some automatic level of basic
> caching? In order to ensure responsive start-up times, it would make sense
> not to contact the remote repository if we already checked it a few minutes
> ago, and would make sense to have a short timeout if we can't contact the
> repository for any reason. I understand that one could keep one's own cache
> and make appropriate calls to PAR::Repository::Client directly if it's
> really desired.
Okay, there's three ways to do caching/optimization here:
1) cache the .par files
2) cache the indices of the repository
3) remember when the indices were last refreshed and only check for
updates every 15 minutes at most
Since the indices can get rather big, I implemented 2) in mid-2008,
before YAPC. 1) *should* be working, but I heard people mention before
that it wasn't working well, so that's something I'd want to have a look
at if I ever had a couple days off with nothing better to do. 3) is not
implemented, but should be easy-peasy -- except for the one thing that
breaks it all. If you use your local copy of the indices and they're
outdated, your request to the server may fail and your application
crashes with a use() error.
Maybe you want to have a look at what I presented at YAPC::EU 2008[1].
It has some info about the hundreds of ways to create .par files as well
as the repository thing (including the ever-ugly and bog-slow
PAR::Repository::Web web front-end).
Cheers,
Steffen
[1] http://steffen-mueller.net/talks/appdeployment/
