Re: Module::Install is a time bomb
On Oct 1, 2008, at 5:11 AM, Andreas J. Koenig wrote: On Wed, 1 Oct 2008 01:04:02 +0300, Gabor Szabo [EMAIL PROTECTED] said: BTW Could I somehow install all the dependencies of a module but not the module itself? You mean like you File::HomeDir requires newest MakeMaker and maybe more but you don't know exactly and just want to look around the uninstalled dependencies? That would be a combination of Ctest Module and Cis_tested. The final step of installing would then be done manually. CPANPLUS commands can be used for that too of course, and there's even a plugin for the shell to do just that: http://search.cpan.org/~mgrimes/CPANPLUS-Shell-Default-Plugins- Prereqs-0.07/lib/CPANPLUS/Shell/Default/Plugins/Prereqs.pm Cheers, -- Jos Boumans If superman is so smart, why does he wear underpants over his trousers? CPANPLUShttp://cpanplus.sf.net
Re: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch.
Steve Hay wrote: Ken Williams wrote: Hi all, After much tireless work by Eric Wilhelm and lots of feedback from patient nonpatient users alike, I'm pleased to announce that version 0.30 of Module::Build is now on CPAN. This is the first non-beta release in a long time. Thanks, applied to bleadperl as 34446. Two local changes remain: Change 32357 by [EMAIL PROTECTED] on 2007/11/17 04:19:47 Skip Module::Build ppm test -- not ready for prime time on VMS. http://www.nntp.perl.org/group/perl.vmsperl/2008/06/msg14821.html The main problem is that Archive::Tar needs a patch to properly be able to pack a VMS binary into a tarball. We were waiting for word from Jos on this. -John Personal Opinion Only
Re: The problem with auto-installing dependencies
* Bill Ward [EMAIL PROTECTED] [2008-09-30T23:07:22] I wasn't talking specifically about anything... the recent discussion about the above led me to post, but I was talking in general about the tendency of module authors to be, in my opinion, overly eager to have dependencies on other modules. Authors are eager to (a) write less code to solve the problem at hand (b) use code that's already tested and I don't think anybody actually rushes out to add dependencies. They rush out to solve problems reliably, and they do that through code re-use. Heck, that's why you're going to the CPAN, too, isn't it? I have never added a dependency to my code when the person paying me for it asked me not to. I bet more CPAN authors are the same way. -- rjbs
Re: The problem with auto-installing dependencies
* Ricardo SIGNES [EMAIL PROTECTED] [2008-10-01 13:45]: I bet more CPAN authors are the same way. Yeah. I often vacillate a great deal about adding dependencies: • I hate making things harder to install. I’m also loathe to give up control if I can’t trust that the delegated responsibility is in formidably capable hands. • Avoiding dependencies forces me to write more code that I’ll have to haul around forever after, often in areas outside my main interest where I don’t have the patience to do a thorough job. I hate that even more. So there are several competing forces at play: how big is the job I need done? Is it going to affect the API I expose? How good is the module I am considering? How big? How many dependencies does it in turn have? How much do I trust the author? And no particular set of answers to these questions is the “right” one. In some cases I add a dependency without any hesitation at all. In other cases I do not even consider dependencies. Usually it takes me a while to decide. It always depends a great deal. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: The problem with auto-installing dependencies
On Wed, 1 Oct 2008, Aristotle Pagaltzis wrote: * Ricardo SIGNES [EMAIL PROTECTED] [2008-10-01 13:45]: I bet more CPAN authors are the same way. Yeah. I often vacillate a great deal about adding dependencies: • I hate making things harder to install. I’m also loathe to give up control if I can’t trust that the delegated responsibility is in formidably capable hands. I really don't think _module_ authors should be worrying about this. Just write your code and depend on whatever makes solving the particular problem you're solving easier. Installation and dependency chains are an issue best solved in the context of _applications_. There are a number of ways to go about this, including system-native packages (where they exist), Shipwright, hand-rolled package all the tarballs and install em, installing a separate perl or separate lib dir per app, etc. Different apps will find different solutions that work for them, and this is largely dependent on the app. For example, if the app can reasonably demand it's own server, system packages work great. If it can't, maybe it's better off automating installing into a per-app lib dir. And of course, an app can simply choose to forgo dependencies altogether. -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: Module::Install is a time bomb
On Tue, Sep 30, 2008 at 2:43 AM, Adam Kennedy [EMAIL PROTECTED] wrote: Really, inc::Module::Build needs to not only be able to know that the installed one is newer than it, but that if that is the case it should use an entry point to loading Module::Build specifically for that it. I'll say it again though: there is no such thing as inc::Module::Build. We're not just putting M::B in an inc/ directory and loading it. The semantics we're working on for people to use are: use lib 'inc'; # Where latest.pm lives use latest 'Module::Build'; # Knows to look in inc/bundled/ The general-purpose logic for doing version comparisons lives in latest.pm . -Ken
Re: Module::Install is a time bomb
Ken Williams writes: I'll say it again though: there is no such thing as inc::Module::Build. We're not just putting M::B in an inc/ directory and loading it. The semantics we're working on for people to use are: use lib 'inc'; # Where latest.pm lives use latest 'Module::Build'; # Knows to look in inc/bundled/ The general-purpose logic for doing version comparisons lives in latest.pm . But what if the bundled version of latest.pm is buggy and I already have a later latest.pm installed on my system? That will use the wrong one!! Smylers
Re: The problem with auto-installing dependencies
On Wed, Oct 01, 2008 at 04:56:32PM +0200, Aristotle Pagaltzis wrote: So there are several competing forces at play: how big is the job I need done? Is it going to affect the API I expose? How good is the module I am considering? How big? How many dependencies does it in turn have? How much do I trust the author? And no particular set of answers to these questions is the ???right??? one. Part of this is why I wrote CPANdeps (http://deps.cpantesters.org/). I'm just about to add links to RT queues, which should be useful too. -- David Cantrell | Godless Liberal Elitist I caught myself pulling grey hairs out of my beard. I'm definitely not going grey, but I am going vain.
Re: Module::Install is a time bomb
On Wed, Oct 1, 2008 at 11:12 AM, Smylers [EMAIL PROTECTED] wrote: But what if the bundled version of latest.pm is buggy and I already have a later latest.pm installed on my system? That will use the wrong one!! latest.pm doesn't ever get installed on anyone's computer. If you install it, we have a backup plan for that too - the guys in black coats will come and take your computer away. -Ken
Re: Module::Install is a time bomb
* Ken Williams [EMAIL PROTECTED] [2008-10-01T12:15:04] On Wed, Oct 1, 2008 at 11:12 AM, Smylers [EMAIL PROTECTED] wrote: But what if the bundled version of latest.pm is buggy and I already have a later latest.pm installed on my system? That will use the wrong one!! latest.pm doesn't ever get installed on anyone's computer. If you install it, we have a backup plan for that too - the guys in black coats will come and take your computer away. Well, at this point we're back to everybody must upgrade everything. Presumably latest.pm knows to use the installed latest.pm if it's later, even if this is rarely true and even more rarely needed. -- rjbs
Re: latest.pm usage
# from Ken Williams # on Wednesday 01 October 2008: The semantics we're working on for people to use are: use lib 'inc'; # Where latest.pm lives use latest 'Module::Build'; # Knows to look in inc/bundled/ Um, isn't that 'inc/inc_*', or did I miss a memo? --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --- http://scratchcomputing.com ---
Re: Module::Install is a time bomb
On Wed, Oct 1, 2008 at 12:02 PM, Ricardo SIGNES [EMAIL PROTECTED] wrote: * Ken Williams [EMAIL PROTECTED] [2008-10-01T12:15:04] On Wed, Oct 1, 2008 at 11:12 AM, Smylers [EMAIL PROTECTED] wrote: But what if the bundled version of latest.pm is buggy and I already have a later latest.pm installed on my system? That will use the wrong one!! latest.pm doesn't ever get installed on anyone's computer. If you install it, we have a backup plan for that too - the guys in black coats will come and take your computer away. Well, at this point we're back to everybody must upgrade everything. Presumably latest.pm knows to use the installed latest.pm if it's later, even if this is rarely true and even more rarely needed. Ricardo: there's no such thing as installed latest.pm. Please go back and read what I wrote above. -Ken
Re: Module::Install is a time bomb
On Wed, Oct 1, 2008 at 9:34 PM, Ken Williams [EMAIL PROTECTED] wrote: Ricardo: there's no such thing as installed latest.pm. Please go back and read what I wrote above. If I understand correctly, latest.pm isn't a module on CPAN, thus is never installed only bundled. I.e. It's not only::latest (http://search.cpan.org/dist/only-latest) Correct? -- David
Re: Module::Install is a time bomb
On Wed, Oct 1, 2008 at 8:38 PM, David Golden [EMAIL PROTECTED] wrote: If I understand correctly, latest.pm isn't a module on CPAN, thus is never installed only bundled. I.e. It's not only::latest (http://search.cpan.org/dist/only-latest) Correct? Correct. It's only executed as part of the build system, not ever installed. In this respect it's just like any code that's in the Build.PL or t/*.t. -Ken
Re: latest.pm usage
On Wed, Oct 1, 2008 at 12:34 PM, Eric Wilhelm [EMAIL PROTECTED] wrote: # from Ken Williams use latest 'Module::Build'; # Knows to look in inc/bundled/ Um, isn't that 'inc/inc_*', or did I miss a memo? Yeah, latest.pm is currently looking in any inc/inc_* for bundled stuff, but that strikes me as kind of dumb actually. I don't know why I used _ as a namespace separator when the filesystem already has a perfectly good / (and the like). -Ken
Re: Module::Install is a time bomb
* Ken Williams [EMAIL PROTECTED] [2008-10-01T21:34:28] On Wed, Oct 1, 2008 at 12:02 PM, Ricardo SIGNES latest.pm doesn't ever get installed on anyone's computer. If you install it, we have a backup plan for that too - the guys in black coats will come and take your computer away. Well, at this point we're back to everybody must upgrade everything. Presumably latest.pm knows to use the installed latest.pm if it's later, even if this is rarely true and even more rarely needed. Ricardo: there's no such thing as installed latest.pm. Please go back and read what I wrote above. I read and understood what you said. Perhaps I should've said, presumably it would be better if... This thread started with Module::Install is a time bomb because, in large part, it bundles code that will not use later code found on the installing system. Then when there is a bug, every author must re-release a dist. That means that a fix to Module::Install means that there must be a thousand more upgrades, one for each dist using it. Module::Build is going to fix that by correctly using the latest Module::Build -- either the one in ./inc or the one in @INC. It will accomplish that by using code that is only found in the dist. That means that when there is a bug, every author must re-release a dist. That means that a fix to latest.pm means that there must be a thousand more upgrades, one for each dist using it. I will admit that bugs in latest.pm (which I have not seen, but can imagine) are less likely than bugs in Module::Install (which I have seen, and wish I could not imagine). It still seems sort of bizarre to have absolutely no nuclear option by which one can deal with 1,234 deployed and broken latest.pms. -- rjbs
Re: The problem with auto-installing dependencies
* Dave Rolsky [EMAIL PROTECTED] [2008-10-01 17:05]: Installation and dependency chains are an issue best solved in the context of _applications_. That just moves the problem, though: an that uses modules with lots of dependencies will demand more build engineering effort. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Module::Install is a time bomb
* Ken Williams [EMAIL PROTECTED] [2008-10-02 04:10]: It's only executed as part of the build system, not ever installed. In this respect it's just like any code that's in the Build.PL or t/*.t. But those are written and maintained by the author. Wouldn’t it make more sense to make latest.pm part of Module::Build proper? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: The problem with auto-installing dependencies
On Thu, 2 Oct 2008, Aristotle Pagaltzis wrote: * Dave Rolsky [EMAIL PROTECTED] [2008-10-01 17:05]: Installation and dependency chains are an issue best solved in the context of _applications_. That just moves the problem, though: an that uses modules with lots of dependencies will demand more build engineering effort. Yes, my point is that it moves the problem to the people who are in the best position to deal with it. The whole dependency problem isn't a problem for module _authors_ like us. If we want to depend on stuff, we install it from CPAN, develop the new module, and release. It's a problem if you have an application that needs to be installed in a system with some sort of constraint. That constraint could be that the app plays well with other apps, that modules can't be upgraded, that all code on the system needs review by someone, etc. The application is also the place where you can come up with multiple solutions, like system packages, install in /opt, custom lib dir, PAR, etc. -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: latest.pm
# from Ricardo SIGNES # on Wednesday 01 October 2008: I will admit that bugs in latest.pm (which I have not seen, but can imagine) are less likely than bugs in Module::Install (which I have seen, and wish I could not imagine). Please see the run-down of usage, and link to sample distribution: http://www.nntp.perl.org/group/perl.module.build/2008/09/msg1665.html It still seems sort of bizarre to have absolutely no nuclear option by which one can deal with 1,234 deployed and broken latest.pms. Please see the -M switch and some code like: unshift(@INC, \fix_the_problem); The fact that latest.pm is very small makes it rather unlikely to be needed and potentially an easy fix if it is needed. One could probably apply that argument to Module::Install too, except for the small bit. --Eric -- Peer's Law: The solution to the problem changes the problem. --- http://scratchcomputing.com ---
