Have any of the people doing the complaining in this thread actually chimed in on the Module::Build mailing list?

Yes. Bug reports and complaints were ignored. When the subject of releasing packages into CPAN _without_ a Makefile.PL came up the reaction was not pleasant. This decision singlehandedly has turned a large part of Perl community against Module::Build. Encouraging people to release unbuildable modules on CPAN was a _bad_ idea, especially as for quite some time no-one on PM on a Win32 box (the single largest group of users of Perl) could even get it installed.

The paranoia and anger in this whole thread is really wacko.

Thanks for your comments autarch. With an attitude like that its no wonder you dont get the issues being raised here. Maybe if folks like yourself took the concerns of folks like us a little more seriously Module::Build would be in wider use, and recieve wider encouragement. I know that from observing the CB there is almost nobody championing Module::Build here, and I think that is a reflection of the poor comunity relations (and decisions) made by the group responsible.

I wish I could be more positive about this actually. I had breakfast with Ken once and I know he is a nice guy. But M::B has definately managed to turn me completely off, and I say that as someone who thought Kens ideas when he presented them were good. (Although iiirc I made the point that breaking the existing Build process was a bad plan even then.)

Yes. Bug reports and complaints were ignored. When the subject of releasing packages into CPAN _without_ a Makefile.PL came up the reaction was not pleasant.

Are you claiming you actually got flamed? I find this hard to believe. Unfortunately, the list archives only appear to be available via the horrid sourceforge archive system, so it's hard to find the thread(s?) you're referring to.

Regardless, I don't recall seeing many instances of people releasing modules to CPAN with only a Build.PL file and no Makefile.PL of any sort whatsoever, so it appears that the people who've decided to use Module::Build have decided that it's best to include both. Certainly, that's what I do with my modules.

Thanks for your comments autarch. With an attitude like that its no wonder you dont get the issues being raised here. Maybe if folks like yourself took the concerns of folks like us a little more seriously Module::Build would be in wider use, and recieve wider encouragement.

Maybe you shouldn't start by accusing the people working on it of being arrogant and criticizing them for things they have no control over (like someone uploading PPMs to CPAN!). That sort of stuff makes it a little harder to listen, since it's hard to find the substance amid the noise being generated.

For example, if you dislike the PPM- prefix used by default, maybe suggest something else (actually, Barbie did, and his suggestions seem reasonable). It's worth noting that there really doesn't appear to be a standard for this. ActiveState appears to use something like "Foo-Bar-0.01.zip" and Randy Kobes' repository uses "Foo-Bar.tar.gz". If Module::Build were to generate something like this, it would obviously be much more problematic than prefixing it with "PPM-".

But really, this whole thread starts from a basic misapprehension of Barbie's, which is that somehow that Module::Build (aka, its developers), by making PPM building easier, is therefore responsible when someone uploads it to CPAN. If PPMs don't belong on CPAN (and I'm thinking that they probably don't) then ask the person doing the uploading to stop. Problem solved.

Are you claiming you actually got flamed?

Well I didnt rate it as a flaming. It was more like "yeah so what you dont like the decision. Thats the decision, its not going to change get over it." It was pretty clear that public opinion, or maintaining backward compatibility was not a priority. As for bug reports, i got tired of sending them out after the first couple were totally ignored. The impression I got was the attitude was like "we dont know who you are and we dont care what you think and oh btw getting it running on Win32 isn't a priority for us." Which essentially lost the efforts of at least one (somewhat) competent Win32 Perl Programmer who normally is inclined to help and to post patches.

Maybe you shouldn't start by accusing the people working on it of being arrogant

Well, I think their conduct and approach to Module::Build has been arrogant. I'm sorry if that upsets you, or that you feel that is unwarranted criticism, but the fact is that is the perception of a lot of people I've chatted with on this subject. Maybe what needs to happen is that the M::B crew actually listens to people, and perhaps even solicits their opinions and thoughts. If the ambition of this project is to change the working processes of tens of thousands of programmers dont you think a little community interfacing should occur?

Let me give you an example, ive seen you post a numer of "defend the module" posts. Have you ever posted a Meditation asking for the communities position on the changes being contemplated by M::B? Have you posted postion documents on CLPM, P5P and the other community locuses? Ive not seen any. Has anybody every asked the folks outside the M::B and CPANPLUS cliques how they feel about things? I bet not because I bet if it were put up to a vote there never would be another Build.pl uploaded to CPAN.

Basically the impression of M::B is: It produces distributions that are unbuildable from CPAN. It doesnt (or didnt) run on Win32. The people involved don't seem to listen unless your name is widely known in the community already.

If you are in a position to change these things then do so and youll see a lot of folks who dis M::B turn into Cheerleaders. Come and tell us we are wacko because we raise issues that are valid in our eyes and you wont win many converts.

Cheers, and respect.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

I recently moved one of my modules over to Module::Build because I don't like make and all the things it entails, and ExtUtils::MakeMaker turned me off due to its complexity and uglyness for expansion.

The first thing that really annoyed me was, that there was no pass-through Makefile.PL included and that I had to hunt down one of your distributions to find a Makefile.PL so that the make && make test && make install dance still works. I don't like make, but it is a very convenient way to unify my automated nightly testing scripts. For something that claims to be the next best thing, this was a bad decision.

Recently, I've gone to writing some meta-packages that automate the installation of other modules, and while battling it out with ExtUtils::MakeMaker, I found it actually not that convoluted and ugly, as long as it is about generating one-shot makefiles and not some ingenious framework to do it all.

I think that the lack of Win32 feedback mostly stems from people shortly evaluating Module::Build under Win32 and then deciding that it's not worth the bother. If you want acceptance, you will have to actively seek out the people there, and not supporting a proper, automatic CPAN installation will not make people like Module::Build, at least, it made me not like it.

The first thing that really annoyed me was, that there was no pass-through Makefile.PL included and that I had to hunt down one of your distributions to find a Makefile.PL so that the make && make test && make install dance still works. I don't like make, but it is a very convenient way to unify my automated nightly testing scripts. For something that claims to be the next best thing, this was a bad decision.

Module::Build has come with Module::Build::Compat for quite some time. Just do this:

Module::Build->new( module_name => ...,
                    create_makefile_pl => 'passthrough',
                  )->create_build_script;
[download]

There are other options that can be passed to "create_makefile_pl". See Module::Build::Compat for details.

The nice bit about this is that Module::Build will simply re-generate the Makefile.PL each time you run "./Build dist". So if Module::Build improves compatibility, you just install the new improved version and next time you create a distro tarball, you get the improved version of the Makefile.PL script automatically.

It comes with that option, but does the option work well?

If you write that as your Makefile.PL and then run it, you'll get error messages. Why? Because you don't have some of the files that passthrough says you require built yet.

If you're like me, you look at it and think that you need Module::Build::Compat to be loaded and run to crate them. So I did that. And got rid of all errors. Then built my tarball.

If you avoid errors by doing that under Linux, you'll actually wind up with an uninstallable tarball. Why? Because certain things have just been loaded by force, and are not overwriteable. What you need to do is have the passthrough, and ignore errors. When you build the tarball, the missing files will be built for you, but not until. (This was the case a few months ago. I don't know if it is now.)

I discovered this only after uploading to CPAN and having a CPAN tester complain about the uninstallable file. I didn't bother reporting the bug after I fixed it because the response the first time that I reported a bug dissuaded me from caring.

Perhaps this is better now. Perhaps not. As I mentioned, I didn't report it so I don't know. Besides, I explained to the CPAN tester what happened, I wasn't the first person that he saw make the mistake, and if that tester continued testing, then any other people making that mistake at least had a good explanation hand-delivered...

The fact that I didn't report it and I don't know whether it is fixed should be a red flag. Something is wrong with how they're dealing with the community. People in the community who're trying to communicate should not consistently become pissed off with the process. Once or twice, it is just some bad apples. If problems are consistent, at some point you really need to stop making excuses and say, "Why am I not being seen like I want to be seen?"

I submit that Module::Build has hit that point and should ask that question.

Why is this option not simply the default then?

That way, Module::Build could have transparently replaced ExtUtils::MakeMaker without any other interference.

For something that wants to replace an existing module, I find the lack of migration paths a major deficiency. And since I found that Module::Build doesn't scratch the itches I have with ExtUtils::MakeMaker, I'm not likely to move the rest of my modules over to it.

Barbie is on crack.

The paranoia and anger in this whole thread is really wacko.

Module::Build has nothing to do with people uploading PPMs to CPAN.

If people are uploading PPMs to CPAN and this is causing problems, then the person doing the uploading should be contacted and/or PAUSE/CPAN should be modified.

I don't think anyone working on Module::Build did use the naming scheme as some sort of "Perl domination scheme"

...assuming Ken & co. have some horrible plot.

Have any of the people doing the complaining in this thread actually chimed in on the Module::Build mailing list?

If you want people to get involved with the development, there are better ways of achieving this than your efforts here in this thread.

I think you need to carefully think that reasoning through. People use Module::Build to create distributions so they can distribute them to a wider audience. Part of that distribution process, in many cases, involves uploading to CPAN. Why should it be automatically assumed that someone who creates a ppm package, using M::B, will not follow the same route as they have for other distributions? While it might not directly upload to CPAN, it is part of the process that people use to upload their modules onto CPAN.

I don't see how M::B will ever be able to create PPMs if the functionality isn't just put in there in some form. I still think it's a big jump to go from that to assuming people will upload PPMs to CPAN, and an even bigger jump to think that this should be discussed by the M::B developers before implementing the functionality. When I wrote some of the initial PPM/PPD-related code way back when, my only interest was in trying to make it easier to make PPMs/PPDs for the DateTime modules.

Why deal with the symptoms, which could cause a myriad of unforeseen problems, rather than look at the root of the problem? Blankly assuming you are right and everyone else is wrong, is not going to solve any issues there might be.

But there have always been tools to create PPMs. The only difference is that now a tool that creates regular CPAN-ish tarballs includes that functionality. This is not a huge radical change. Regardless, if PPMs don't belong on CPAN at all, there not much to be done besides asking people not to upload them there.

Wildly claiming I am "on crack", have a "fevered imagination" and an "overwhelming ego" is nothing short of a personal attack.

Well, I only wildly claimed you were on crack. The fevered imagination I attributed to demerphq, and, the "overwhelming ego" quote you've taken way out of context. I wrote "instead of assuming Ken & co. have some horrible plot, or are motivated by some sort of overwhelming ego ...". That wasn't directed at you or anyone else. If you want to be offended, at least be offended at what I actually said. I'm not even particularly irritated at you, though I think your original post is off the mark, since this problem has a lot more to do with one person uploading something to CPAN than Module::Build. I am irritated at the various responses which seem to just go along with that assumption and then blame that on the fact that there is some sort of attempt by Module::Build to take over the Perl community, or some other ridiculous theory.

As I've said, if there's a problem with the PPM generation of Module::Build, I think that people who actually use Windows would be greatly welcomed if they have ideas and/or code to contribute, because I know that I, for one, have no freaking clue about Windows, despite having written some of the PPD-related code.