Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

What's wrong with PREFIX, you ungrateful fucks.

by schwern (Scribe)
on May 18, 2005 at 21:15 UTC ( #458436=note: print w/ replies, xml ) Need Help??


in reply to Module::Build users -- please use the "traditional" create_makefile_pl option

Ok kids. I've had the "what's wrong PREFIX discussion" so many times, discussed it on p5p, makemaker@perl.org and module-build-general since, oh, 2002 when it was the VERY FIRST THING I tried to repair in MakeMaker and the whole reason why the mess ended up in my lap and concluded it cannot be fixed TWO YEARS AGO. There's no conspiracy of silence, YOU'RE JUST NOT LISTENING! I'm sick of hearing "but it works for me" or "I've never seen where it gets things wrong" that I've finally put up a link on makemaker.org about it. It only screws up on weird, little used operating systems such as OS X. Additionally, an explaination is in the Module::Build docs (0.27 branch).

Why PREFIX SUCKS

Module::Build (and now MakeMaker though its undocumented, doc patches called for, none received) has --installbase which is much simpler and more predictable than PREFIX can ever be. Additionally Module::Build is working on a .modulebuildrc file so you can store your installation preferences rather than having to specify them on the command line all the time thus fixing a very long standing MakeMaker problem. Those interested in helping can join module-build-general@lists.sf.net. and/or makemaker@perl.org. Those interested in complaining can continue to post irrelevant rants here.

As to why its taking so long to get PREFIX support into Module::Build... its because I'm lazy, its because its hard, I'd have to untangle the prefixification logic from the MakeMaker object, its because I've got a dozen more critical MakeMaker things to work on, its because I retch whenever I think about touching the fragile logic of PREFIX. Of course, this is open source. ANY ONE OF YOU could have taken a shot at this. Total patches or attempted patches I've received: zero.

However, I did commit to doing this at the last OSCON so I will do it before the next.

And thank you all for the COMPLETE LACK OF RESPONSE I got when laying out a future roadmap and todo list for MakeMaker which includes modularizing PREFIX so it can go into Module::Build. Your utter lack of help and patches to improve the code you complain about is understandable. You have fullfilled your part of the Open Source economy by posting up your complaint and FUD-based suggestions, which I then have to spend time countering, with no patch, on a web forum that the authors in question probably will never read (I don't, I had this thread pointed out to me by a friend).

I'm not bitter at all, you ungrateful fucks.

20050520: Unconsidered by Corion: 7/5/0 for title change to What's wrong with PREFIX, you ungrateful f***s.. This is at least the second such unconsideration, and I remember the others being at 20+/20+/0 (but I don't remember the title anymore). So don't consider this node for a title change anymore, please. Please look at previous considerations before considering again.


Comment on What's wrong with PREFIX, you ungrateful fucks.
Re: What's wrong with PREFIX, you ungrateful fucks.
by perrin (Chancellor) on May 18, 2005 at 21:46 UTC
    So, back to the topic of this thread, how about encouraging people who are not actually using any Module::Build features that aren't compatible with MakeMaker to use the "traditional" option? Can we all agree on that?
Re: What's wrong with PREFIX, you ungrateful fucks.
by samtregar (Abbot) on May 18, 2005 at 22:39 UTC
    However, I did commit to doing this at the last OSCON so I will do it before the next.

    That's good to hear. You can rant and call us names if you like. In the end, it's just the code that matters.

    Thanks!
    -sam

Re: What's wrong with PREFIX, you ungrateful fucks.
by Anonymous Monk on May 19, 2005 at 02:35 UTC
    You're the one who keeps pushing Module::Build like it's the new sliced bread. You're the one who keeps pushing Module::Build::Compat as if it provides compatibility. When people complain, you say "well send the patches." When people send patches, you don't incorporate them, until 30 release cycles later when someone sends then again. Ungrateful? You just want your ego stroked.
      It's *schwern*. I say if he's angry, he has a right to be angry -- plus, he says stuff like that from time to time. We know him.

      It's not like some anonymous person came by and questioned the motives or rationale of someone established within the community...oh, wait...

        he says stuff like that from time to time. We know him.

        I think his homenode says it best:

        @Schwern::ISA = qw(Loon);

        We're not surrounded, we're in a target-rich environment!
Re: What's wrong with PREFIX, you ungrateful fucks.
by castaway (Parson) on May 19, 2005 at 07:39 UTC
    Nice rant.

    I've just read through that ML discussion you pointed to, and I have to admit I'm still in the dark about why PREFIX is bad. Bear with me a minute. I see there two problems mentioned:

    1. That using it under OS X produces somewhat weird paths - Ok, so mention in the docs that PREFIX under OS X isn't a good idea.
    2. That setting PREFIX and MANPATH, LIB etc at the same time makes a potential mess. - Now, I can't think of a reason I'd want to do this, except maybe to say "Put man pages here (MANPATH) and everything else over there (PREFIX or whatever). And if I wanted to do that, I, as the user/installer would expect to be warned by the programm that, for example, I needed to have MANPATH first, and PREFIX after, or some such. In general I'd settle for: if someone wants to set one dir specially, then they'll need to set them all that way, and can't have PREFIX in there at all.
    Are there other cases I'm missing?

    I generally get the feeling that people are too hung up on the "special cases" of PREFIX, and won't seem to admit that, usually, anyone using PREFIX just wants to say "stick everything under this directory", and has PREFIX as their only extra argument. All this doc discussing reflects this problem. Were I to have a say, I'd make PREFIX just do that, and warn whenever it is used together with other potenially conflicting variables.

    One other thing I noticed in that discussion. It seems to imply, that when using PREFIX with Makefile.PL, your PERL5LIB automagically gets set to whatever you used in PREFIX. That's never been the case for me, when I've wanted to install a bunch of modules that depend upon each other, in a particular directory, I've had to set PERL5LIB manually after the first one, so the others can find it. Have I missed some innovation there, or am I misunderstanding the discussion?

    Last thing: Software doesnt have to be perfect, even in this case. It just needs to document what it can do, and not do, and warn suffciently if the user does something that won't produce useful results. Add the functionality, document it, and let the user worry about how they are going to use it, because I'm still convinced, that in 99% of the cases, the person installing the module will not stumble across the edge cases.

    C.

    Oh, and Module::Build should definitely complain if it gets arguments it doesn't know, silently ignoring is a recipe for disaster IMO. (Images of people screaming "why didnt XYZ work?" - sorta like strict, y'know, a typo checker..

      Does not the 'install_base' parameter provide the "stick everything under this directory" functionality?
        I expect it does. My question boils down to: Why isn't the answer to "Where is PREFIX?" just "install_base does the same thing", which is correct in 99% of cases that anyone cares about. Instead there seems to be always a long discussion about how bad PREFIX is, that never actually gets to the point.

        NB: I have most likely not read all existing discussions on the subject, so this is just a synopsis of those on PM that I've seen.

        C.

Re: What's wrong with PREFIX, you ungrateful fucks.
by Corion (Pope) on May 19, 2005 at 12:03 UTC

    Spectacular rant!

    I don't buy the "doesn't work on OSX" thing. From what I know, OSX is merely a BSD and thus can create symlinks. So all users of PREFIX= on OSX that want a private library will likely have created symlinks that make sense for the stuff that Perl/EU::MM does anyway. I have not seen any description on how I can make my installation which uses PREFIX= coexist peacefully with the breakage that Module::Build introduces. Telling me

    Note that this is different from how MakeMaker's PREFIX parameter works.

    does not solve my problem. Telling me how to emulate (my current version of) PREFIX= via install_path would help maybe. Forcing me to redo the whole installation just because some people are too blinded to use EU::MM is not.

    To me, the "utter lack of help" stems from the fact that module installation is a solved problem, and Module::Build is a reinvented wheel that hasn't really proven it's better (and, on Win32, it was much worse for a long time). Currently Module::Build is chiefly different, but while being different seems to work for Apple, it's not enough for Module::Build. As I don't have any problems with EU::MM, and have had enough problems with Module::Build, I simply don't use Module::Build, and advice others to do the same. Until Module::Build gets better documentation and/or better features that bring it up to par with EU::MM (debugging of a Makefile is trivial opposed to debugging why and where a Module::Build script fails!), that won't change.

      Corion wrote: To me, the "utter lack of help" stems from the fact that module installation is a solved problem, and Module::Build is a reinvented wheel that hasn't really proven it's better ...

      Module installation is most definitely not a solved problem. MakeMaker is a spectacular hack that does a wonderful job of handling the majority of needs that most people have but it is not a full-fledged build system. Schwern talks about how difficult it was to try and get MakeMaker to work on Mac Classic and VMS, but they were trivial to add to Module::Build because it's pure Perl. And while it's not public yet, I can guarantee that the sophisticated build work we're doing for Bricolage 2.0 would be very difficult under MakeMaker. Some build requirements (such a variable dependency lists) are beyond the capabilities of MakeMaker primarily because of how difficult they are to add. And does a new OS pop up? Once Perl is ported, there's a good chance that Module::Build will get ported to it immediately and just work. Can't say that for MakeMaker.

      MakeMaker is really hard to extend and modify. One day Schwern needs to sit down and try and remember all of the features that he's rejected in MakeMaker because of this. With Module::Build, you have a robust, full-featured build system that's easy to extend, modify, and fix. PREFIX isn't in it yet because of how difficult that is to extract from MakeMaker. Of course, if anyone disputes this, the proof is in the patch.

      Module::Build (and I say this with the guilty admission that I haven't ported my modules yet) is the future of build in Perl. It's not where it could be but that is due, in large part, to the fact that many, many years of arcane hacks and business knowledge are squirreled away in the internals of MakeMaker and that's not always easy to port (or well-documented, either). Of course, the fact that people won't use Module::Build until it's perfect doesn't help, either.

      Cheers,
      Ovid

      New address of my CGI Course.

        I don't buy the "Module::Build will Just Work" crap. I have seen how it doesn't work on Win32, and mostly because of unixisms used. So if the New OS is unlike Unix, Module::Build will not Just Work.

        I don't think that Module::Build needs to be extensible. Period. It should get my modules installed. My modules could be installed by a glorified shell script, and if I was keen about worrying, I could use ExtUtils::Command to replicate the functionality myself instead of relying on EU::MM. But I don't want to do that, and EU::MM already works.

        I hear Schwern talking when you say Module::Build is the future of build in Perl. Module::Build may indeed be the future of Perl, but it will never be the future of build in Perl5. Perl6 has the luxury of starting from a clean slate and not having to worry about previous bad decisions. Perl5 has PREFIX=.

        All the devs keep complaining that nobody uses Module::Build, and then keep complaining again when shortcomings get reported. They also complain about how bad EU::MM is, and they complain that their work on Module::Build is not recognized. I see a pattern there, and I guess that comes into play when considering on what I spend my time.

        The Module::Build cabal thinks itself the herald of the future (and behaves like it). This makes them blind and deaf against their users. Which is bad if you wantneed a large user base. If Module::Build does not provide an easy migration path for both, modules and existing installations, it will not go anywhere. And I have not seen any consideration of the Module::Build cabal for existing Perl installations. And the cabal cannot take the hint from the complainers that don't use Module::Build. Because, usually, after two or three complaints, people keep using what they used before (EU::MM) instead of putting up with the Module::Build cabal.

Re: What's wrong with PREFIX, you ungrateful fucks.
by Corion (Pope) on May 19, 2005 at 17:01 UTC

    I just realized what has been irking me about this attitude. Why should I be grateful for something I did not want or request? I want a working module installation kit. I have one that works. I point out flaws and incompatibilities with a second kit, that somebody created. Am I ungrateful because of this?

      No, but you've comitted the sin of confusing schwern you ungrateful

      This response has always bugged me. I’ve read this thread at least three times (once when it was posted and then several more times when it was linked from discussions elsewhere), but I could never quite put my finger on why.

      It just dawned on me.

      Yes, you are ungrateful – not directly, but you are. The reason is that schwern is the maintainer of the install kit that you say is working for you. And for him, it’s incredibly painful to maintain. So he says “I can’t do this forever, it needs to stop,” and starts a new effort, which is expectably immature, while he continues to maintain the old one. And you just say “well the old one works for me (and who cares about your pain) and the new one doesn’t (and who cares about your pain).”

      Given the position he’s left in, as far as I’m concerned, you should be glad he didn’t say “screw you guys, I’m going home” long ago and left the “working” EU::MM lying in the sun to rot. Instead it continues to get bugfixes. That’s not worthy of gratitude?


      To give a nod to the original topic of the thread: I always do use create_makefile_pl => 'traditional', because I’m not going to force an immature module on my users. But I do believe M::B is the only sensible option in the long term, so I have switched – as a bonus, I get a bunch of nice author-oriented features. Come the day that it’s considered mature, I will drop the Makefile.PL generation. In the meantime, M::B::Compat lets me have my cake and lets my users eat it too.

      Myself, I am very thankful that others are doing the boring and painfully tedious job of getting the plumbing right, both the legacy stuff and the modern stuff, and I’ll do whatever I can to promote the modern stuff without making users suffer for it.

      Makeshifts last the longest.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://458436]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (15)
As of 2014-07-24 15:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (161 votes), past polls