All the Perl that's Practical to Extract and Report

CPAN fails to self install :(

barbie on 2007-02-16T16:48:40

It seems this is not a new bug for CPAN.pm on Windows. I have been quite happy with the version of CPAN.pm I'd been using, but it was now a few versions behind, so finally decided to 'install CPAN' from within the 'cpan' shell. It downloads and tests fine, but then falls over trying to install over a file that is being used ... by CPAN.pm. This is either a flaw or feature of Windows, depending how you look at it, but it does regularly seem to catch people out. Installing it through the 4 stage command line route worked fine, so it is now installed, but it did make me wonder why it has to be this way.

Whatever complaints you might throw at Windows, most application installations work really nicely, even the various Perl binary installations are all point and click. It's a pity we have to get so low level for the individual libraries.

I'm even tempted to offer someone a metre of beer (as is Adam's fashionable wager) to see if they can write a binary installer (that could potentially run on Win32, Linux, Mac OS X, Solaris, etc) that hides all the CPAN/CPANPLUS/MakeMaker/Module::Build gubbins from the user and just installs by the use of a file extension association.

The .ppd (Perl Packaged Distribution) extension used by ActiveState is a good start, but would probably need a different type of XML or other markup to work well cross platform/perl.

The problem has been mentioned several times before, but I don't believe anyone has figured out a suitable way of solving the problem. To some it might not be seen as a problem, but when other libraries have cross platform point and click installations, I'm wondering whether this is another reason why the take up of Perl hasn't been so good in recent years as it has with other languages.

Or maybe it's just down to having a more complete binary package repository, that has a wealth of CPAN distributions packaged for several platforms. There are already several PPM and RPM repositories, which potentially could be combined.

Or maybe a GUI, like Synaptic, is needed that can do the searching, pointing and clicking and then hide all the nasty IO between the actual installers, except were necessary or requested of course. In fact I like that one better. It could even be written in Perl (with Tk?) and packaged with PAR as an executable.

I'm tempted to offer a metre of beer, but I'm also tempted to try this one myself. However, I still have plenty of other projects on the go and starting another is probably not a good idea. Perhaps I should finish those other projects first :)

PPM is cross-platform

kungfuftr on 2007-02-16T19:08:26

Um... PPM _is_ cross platform. The problem facing doing a large binary build is making sure that it'll work on each OS, OS version, architecture combination. There's a _whole_ bunch of work involved there along with the problems around needing to package up underlying libraries (libgd, etc).

Not impossible, but tricky.

Re:PPM is cross-platform

barbie on 2007-02-17T08:52:16

I know PPM is cross platform, but it isn't point and click and isn't a GUI that allows you to search and select installs. It also shows you all the installation text instead of to a log or similar, when the user only needs to know errors and necessary interaction questions.

Re:PPM is cross-platform

tsee on 2007-02-17T10:19:49

The newest PPM (version 4) that comes with AS Perl has a GUI. It will not be available outside AS Perl, however.

ExtUtils::Install

dagolden on 2007-02-16T23:09:08

demerphq fixed this already in ExtUtils::Install. Of course, you need to find a way to get that installed, too.

Strawberry Perl includes it by default on Win32, even though it's more advanced than the version in core 5.8.8. Whenever ActiveState does as well, it should be possible for CPAN.pm to upgrade itself or any other core module there, too.

That doesn't address the "double-click to install" idea, but that's probably not more than a hackathon away with either PPD or PAR.

Re:ExtUtils::Install

barbie on 2007-02-17T09:06:16

Strawberry Perl includes it by default on Win32

In that case you have a bug, as I'm using Strawberry Perl :)

.. but that's probably not more than a hackathon away
What a good idea, I might have to suggest that for Birmingham.pm's big thing in the summer. Personally I'd love to have something like Synaptic that can search 02packages.details.txt and install through the normal mechanisms, with a preferences option to automatically send to cpan-testers ;)

Re:ExtUtils::Install

dagolden on 2007-02-17T13:31:27

In that case you have a bug, as I'm using Strawberry Perl :)

Ouch. Could you please open up a bug on rt for Perl-Dist-Strawberry with more details? It "works for me" so I'd like to know specifics about your setup.

One standard Windows suggestion -- have you tried it after a reboot? ExtUtils::Install knows when a reboot will be necessary after an install, but there is currently no communication back to the user about it.

Re:ExtUtils::Install

barbie on 2007-02-19T16:57:09

I hang my head in shame for casting aspersions. I wasn't paying attention and I wasn't using Strawberry Perl at all. I've just tried the Strawberry Perl upgrade and it all seems to work quite nicely. I think I now owe you beer (maybe even a metre if the glass is thin enough ;)) for causing untold stress over the weekend :)

ExtUtils::Install knows when a reboot will be necessary after an install, but there is currently no communication back to the user about it.

That suprises me, as looking through the code, I would have assumed it did announce a reboot is required during _do_cleanup() called from install(). It certainly didn't say a reboot was required when I upgraded. I guess i must be missing something there.

Re:ExtUtils::Install

dagolden on 2007-02-19T21:10:40

I forgive you. I hope to have a chance to collect the beer at a conference or hackathon one of these days.

The ExtUtils::Install is tricky -- it would be nice if it could communicate back to CPAN, but it's run in a subprocess of a subprocess, etc. so it can't. Maybe CPAN could set an ENVIRONMENT variable if it wants ExtUtils::Install to pop up an alert box or something. I need to remember to bug Andreas and Yves about coming up with something more user friendly.

Re:ExtUtils::Install

barbie on 2007-02-19T22:32:48

I may have been a little too excited too soon. It seems the upgrade has trashed my registry :( I keep getting ribbed about running Windows when I talk at LUGs, maybe I should finally get round to dual booting at last :)

Re:ExtUtils::Install

dagolden on 2007-02-20T00:12:47

Please come bounce issues off people on #win32 -- perhaps we can figure out what the issue is.

Me too

tsee on 2007-02-17T10:30:20

You're not the first one to wonder about why there aren't better end-user tools for installation of Perl packages. Adam Kennedy, David Golden and myself banged about various ideas in that regard for quite some time on IRC, via mail, and the win32.perl.org wiki. Adam is tackling the problem from a conceptual pov. now.

It turns out that this is a major effort - writing a package manager would be hard enough, but possible. What's incredibly difficult is extracting all the necessary meta data and providing a repository of everything CPAN. It all boils down to needing a lot of maintenance which is something we can't even do for CPAN alone. Furthermore, external, non-perl dependencies are still completely unsolved.

Anyhow, a slightly different approach would be to write a GUI that can just deal with all the existing resources instead of coming up with a completely new repository infrastructure. I haven't done a lot of work in this field, but you should read my journal entry on this: http://use.perl.org/user/tsee/journal/31988

The outline program isn't beautiful nor is it overly convenient, but at least it can install PPD/PPM packages into Strawberry Perl via a GUI and uninstall modules.

Even for its limited scope, there's still something missing I'd deem very important: The ability to modify a perl that isn't in the same place as the Perl it was built from. So it might only work for strawberry-perl installations. I have done some infrastructure hacking in this regard. This is what fuelled my recent modifications of ExtUtils::Install and the creation of ExtUtils::InferConfig. Combining these, one should be able to let the user choose a perl.exe in a file browser and let the program figure out where files need to be put. It's just some GUI hacking away, but I haven't gotten around to it yet.

Cheers,
Steffen

If it's failing in current strawberry, that's bad.

Alias on 2007-02-17T16:46:30

As far as I'm away the problem you report does not exist anymore and was fixed a while back. If it's regressed I'd like to know how it has done so.

Do you have multiple Perls installed (could be problems hiding there).

Can I suggest you drop in on #win32 in irc.perl.org and let us help you?

The only pending bootstrap fix I'm aware of is the whole forced/auto-upgrade thing, but that's going to have to wait for 5.10.1 since the fix needs to exist on initial installation.

NOW, as for a GUI, that's been an idea I've wanted for a while.

For starters, have a look at pip. Not as a starting point as such, but to see what else is going on in this area.

Second, if you are going the GUI route, PLEASE use WxWindows. It's the only GUI toolkit we have that we know for sure will install on all three major desktop platforms, and enormous amounts of work have done into making it work properly.

This sort of installer is one of the main parts of what I've previously called the "Chocolate Perl" concept. Start with Strawberry, and add a bunch of GUI user-friendly tools for Windows people that are new to Perl (where Strawberry is for Perl people that are new to Win32).

And again please hang out in #win32. All the cool kids are there.

Re:If it's failing in current strawberry, that's b

barbie on 2007-02-19T17:18:11

Do you have multiple Perls installed

That was the problem, I'd previously been switching between Strawberry and AS, and thought I was still in Strawberry.

Can I suggest you drop in on #win32 in irc.perl.org
Unfortunately I'm not good at IRC, as I usually find it too distracting. The only time I usually use it is during a YAPC to figure out what talk I should be in :)

have a look at pip.
That's certainly along the lines of what I was thinking for a point and click install file, and there should be no reason why a GUI application couldn't be associated with that file type and run the command line installer interactively. However, I was thinking of taking it further so it acts as a desktop search of CPAN, but instead of a download button you have a select button. Then when you click to apply your selections, it'll check dependencies and tell you all the extra modules you'll need to install. Then when you click okay, it will go and install them with as minimal fuss as possible. At the moment you only get to know about the dependencies as the installer gets to each module in the chain.

PLEASE use WxWindows.

I didn't have much fun with it last time I looked at it, but that was over 3 years ago, so i guess it might have improved some since then.

And again please hang out in #win32. All the cool kids are there.

Ah now see there's your problem, there is no way I could ever be considered cool. A misfit maybe, but never cool ;)