Re: Module::Build::Tiny
# from Aristotle Pagaltzis # on Sunday 28 August 2011 22:50: In my understanding, the complexity of Module::Build piled up because the same tool tries to cover both installation and authoring use cases. I've often had that thought, though I would say that M::B definitely suffers from being a mature codebase largely lacking its original author and large amounts of test coverage where small changes could break the CPAN -- so, that tends to stifle innovation (in my personal experience.) The compat code (involving various forms of Makefile.PL workarounds) is also a burden, as is coding to be compatible with anything older than 5.8. But I don't think there are really enough authoring features for that to be a major source of complexity. The subclassing as customization design leaves a lot to be desired and makes it difficult to ever change or refactor the internals API without breaking someone's distribution. There is also almost a decade of transition coded into it (e.g. TAP::Harness vs Test::Harness) and a lot of code just to guard against being used in ridiculously old installations. Plus, strange things that happen when you mess with PERL5LIB / -I / 'use lib', etc and expect that to propagate throughout your tests across processes regardless of whether you're running red hat or not. We'll see if MBT has to run the same guantlet. I believe the Dist::Zilla approach is a better way to take care of authoring... So Dist::Zilla plus the *idea* of Module::Build::Tiny seem to fulfil the original concept of Module::Build better than that module itself ever has. If you're using Dist::Zilla, you *should* not need anything besides META.json to install a simple module if you just set dynamic_config=0. (This should is, of course, largely unimplemented.) Also, I think that M::B is better as a customizable deployable build tool than as an author tool. I think it was even conceived as just that and only years of feature creep have added a lot of author tools. But is the implementation up to par? ... (I’d also be interested in whether any omissions mentioned in the POD are design choices or the idea is to add them in the future, and which if so.) There might be some trouble being compatible with some of the more obscure features of buildrc and the env (which somebody always seems to have setup in a way which you have never thought necessary or logical.) It does seem to have factored-out many functions which M::B had as (maybe misplaced) methods. Overall, it looks interesting, but I would hope that it at least adds some runtime support if not also C/XS. Without the ability to have dynamic prereqs or build C/XS, why do you need a Build.PL at all? You have to assume that the client supports 'configure_requires' or the user has already installed MBT for this to work. If the Build.PL is a compatibility workaround, that seems like a weird niche to me because needing 'configure_requires' means you need a client from the last few years and 'dynamic_config' has been around longer. Sadly, cpanm seems to not support dynamic_config. I'm not sure whether one of the other two clients can satisfy prereqs from META, run `prove -lr t`, and install the files from lib/ yet. --Eric -- Insert random misquote here --- http://scratchcomputing.com ---
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Sun, Aug 28, 2011 at 2:38 PM, Arthur Corliss corl...@digitalmages.com wrote: Google switching to SSL by default is as pointless as metacpan. In the former case it's the protection of delivery to/from an entity that not only doesn't have your best interest at heart, but has a business built on exploiting *your* information for *its* benefit. Utterly pointless. I'll take this bait, swallow it, and hopefully bite off the line: Yes, Google is going to use query data for its gain. But, Google's business model also involves *aggregation* and *respecting individual privacy*. The SSL to Google Search is supposed to protect one from eavesdropping, as has been pointed out, by the other people in Starbucks. And it does this. Say you're sitting in Starbucks, searching for clues concerning an embarrassing medical condition. Your risk is, Mallory will intercept your packets and tell his buddies and they will huddle and point. If some Google tech sees your query among the millions of other queries and points it out to /his/ buddies and they huddle and point, that doesn't affect you the same way, if at all. They won't be pointing at you, the victim of an embarrassing medical condition, they will be merely pointing at an evidence of your existence. And such attention might actually bring more attention, in general, to the problem of severe triskaidekaphobia or whatever, which would be a good thing for you -- in the aggregate. The resulting open discussion of severe triskaidekaphobia might help lift the crippling stigma that has followed the victims for so long, without any unpleasant direct confrontations.
Re: Module::Build::Tiny
On Mon, Aug 29, 2011 at 1:50 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote: I find this module intriguing. Thank you. It grew out of Acme::Module::Build::Tiny -- which was an exercise to determine the *minimal* API that Build.Pl/Build needed to allow the toolchain to install a module. (Thus cutting out all the authoring cruft that bled into Module::Build over the years.) Kudos to Leon for taking it from Acme and making it real. In my understanding, the complexity of Module::Build piled up because the same tool tries to cover both installation and authoring use cases. That is one part of the complexity (OO subclassing is the other part). I suspect that the majority of the lines of code are due to author support, not installation support. But is the implementation up to par? Essentially: if I’m using Dist::Zilla for authoring, what regular features not explicitly mentioned in MBT’s POD would I have to avoid? Do things like optional or build-/test-only deps work? (I’d assume these do.) Or can I assume that everything will work unless otherwise pointed out? I haven't used it in my own modules. With Dist::Zilla to hide the ugliness of Makefile.PL from me, I just let it use that. Most if not all of what dzil does should still work. The exception would be plugins that want to hack directly on a generated Makefile.PL (e.g. Dist::Zilla::Plugin::DualLife). I could answer this for myself if I had *exact* understanding of how much of the work falls upon the .PL at install time, and how many of the toolchain features are implemented in the CPAN client and thus unaffected by MBT’s minimalism. MBT uses many external libraries (many core, some not yet core :-) to do what it does. Here's a very simplistic version of the install process (not specific to MBT): * PL -- resolve any dynamic configuration issues; write prereq data into somewhere the toolchain can find it (MYMETA is the new standard, but EUMM and MB had their own custom ways to do it); alert users to things missing * make/Build -- assemble all files to be installed into blib/ -- for pure perl module, this is usually just copying from lib/, unless there are other foo.PL modules to generate foo.pm; for C/XS modules, a lot of libraries are needed to compile the XS, location the C compiler, etc. This is ugly, complicated stuff to get right portably, which is why MBT doesn't do it (yet) * test -- run tests in t with Test::Harness (or possibly TAP::Harness); the make/Build tools is responsible for determining the list of files to run, including possible recursion in t/, as well as setting any necessary environment variables (e.g. PERL5LIB) * install -- assemble a manifest of files to be installed from blib/ and hand off to ExtUtils::Install to do the dirty work One of the hard parts throughout the stuff above is getting the library paths correct. For installation, that means sorting out where to install given PREFIX/INSTALL_BASE or custom library paths. For testing, that means ensuring the right PERL5LIB/PATH given the various ways they could be set, e.g. in an original PERL5LIB, via -I bar flags to perl Makefile.PL or perl Build.PL, or via use lib statements in *.PL (More that you wanted to know, perhaps.) (I’d also be interested in whether any omissions mentioned in the POD are design choices or the idea is to add them in the future, and which if so.) I don't personally plan to do more work on it now that the Build.PL/Build API has been demonstrated. I'll leave that to Leon to respond to. Most of the original Acme::Module::Build::Tiny limitations were design decisions to stay consistent with the Tiny philosophy of providing 90% of the functionality of the heavy module in a fraction of the code. I wasn't trying to rewrite M::B. I was trying to write a new, minimalist replacement sufficient for most things on CPAN that didn't require any changes to CPAN/CPANPLUS/cpanminus. Eric raises the question why bother and I think for module authors, at least right now, there is no burning platform to switch. Schwern has been trying to get people to stop using EU::MM for years and I think the MBT is a stepping stone towards that vision. Once it figures out the hard bits of interacting with the toolchain, it should be relatively easy for it or successors to add the missing features within a well-defined framework. Perl 5.10.1 supports configure_requires and is already unsupported by P5P, though the Perl toolchain maintainers have an informal agreement to support older Perls (5.6 at least, though that may shift to something in the 5.8 series with decent Unicode support before long). By the time that MBT has enough track record for widespread adoption, I would hope that Perl 5.10.1 becomes the oldest perl supported by the toolchain and then MBT or other Build.PL solutions will be the future and we'll finally put a stake in the heart of ExtUtils::MakeMaker. -- David
Re: Module::Build::Tiny / dynamic_config=0
# from David Golden # on Monday 29 August 2011 08:07: Eric raises the question why bother and I think for module authors, at least right now, there is no burning platform to switch. I think you misunderstand my point. Given dynamic_config support, there is no need for a $builder_or_maker.PL for the simple case. I was trying to write a new, minimalist replacement sufficient for most things on CPAN that didn't require any changes to CPAN/CPANPLUS/cpanminus. As for a demonstration of implementing the Build.PL interface: yes. But I think the CPAN clients should eliminate it by supporting dynamic_config. I haven't experimented to see what the current state of this is, but CPAN.pm has dynamic_config support in the prereqs (not sure about test+install.) I think the most complicated part is supporting whatever builder+installer assumptions people have encoded into their configurations -- maybe the client could read buildrc? --Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White --- http://scratchcomputing.com ---
Re: Module::Build::Tiny / dynamic_config=0
On Mon, Aug 29, 2011 at 2:25 PM, Eric Wilhelm enoba...@gmail.com wrote: I think the most complicated part is supporting whatever builder+installer assumptions people have encoded into their configurations -- maybe the client could read buildrc? For that, I'd prefer to see a new way for CPAN clients to share common configuration information. Think how ~/.gitconfig provides config info used by lots of git ecosystem tools. I'd like that for CPAN so one isn't configuring mirrors, INSTALL_BASE, etc. for each client individually. I had some stub code for that, but have set it aside in favor of other projects. I don't think .buildrc is the answer, though. It has a number of limitations, particularly with respect to paths with spaces. -- David
Re: MetaCPAN is quickly becoming the de-facto interface to CPAN
On Mon, 29 Aug 2011, David Nicol wrote: I'll take this bait, swallow it, and hopefully bite off the line: Yes, Google is going to use query data for its gain. But, Google's business model also involves *aggregation* and *respecting individual privacy*. The SSL to Google Search is supposed to protect one from eavesdropping, as has been pointed out, by the other people in Starbucks. And it does this. Say you're sitting in Starbucks, searching for clues concerning an embarrassing medical condition. Your risk is, Mallory will intercept your packets and tell his buddies and they will huddle and point. If some Google tech sees your query among the millions of other queries and points it out to /his/ buddies and they huddle and point, that doesn't affect you the same way, if at all. They won't be pointing at you, the victim of an embarrassing medical condition, they will be merely pointing at an evidence of your existence. And such attention might actually bring more attention, in general, to the problem of severe triskaidekaphobia or whatever, which would be a good thing for you -- in the aggregate. The resulting open discussion of severe triskaidekaphobia might help lift the crippling stigma that has followed the victims for so long, without any unpleasant direct confrontations. I think you're still missing my point and focusing on defending a company you obviously like. Contact me off the list if you want to discuss/debate the actual dangers that companies like Google present. Otherwise, let's focus on the crux of my argument: trusting any third party with your personal information whose primary business is selling the use of your information is foolish, and the use of SSL as your conduit to them should not make you feel safer. That company is liable to be a greater danger to your privacy than random wifi eavesdroppers. Likewise, the use of SSL to conceal your access of highly public (and specialized) information on metacpan also provides no tangible benefit for 90% of the users. They should offer SSL as an option, but not mandate it for those of us who derive no benefit from it. Again: a resource like metacpan should aim for maximum accessibility... --Arthur Corliss Live Free or Die
Re: Module::Build::Tiny
On Mon, Aug 29, 2011 at 7:50 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote: I find this module intriguing. I'm happy to hear that :-) In my understanding, the complexity of Module::Build piled up because the same tool tries to cover both installation and authoring use cases. There are many things that contribute to that. I think there's a more general everything-and-the-kitchensink issue going on in Module::Build. In Module::Build::Tiny I'm trying to go into the opposite direction: modularize everything that's reusable so the central module is actually quite small and simple. But is the implementation up to par? Not yet, but it's getting close. I'm still dealing with some portability issues, but the core idea of it seems sound. For a pure perl module that runs only on Unix on perl 5.10.1 or higher, it should be up to par now already. If not bug reports are welcomed. I'm only using it for two relatively unimportant modules so far, but I'm planning to try it with more modules as soon as the known issues have been ironed out. Essentially: if I’m using Dist::Zilla for authoring, what regular features not explicitly mentioned in MBT’s POD would I have to avoid? Do things like optional or build-/test-only deps work? (I’d assume these do.) Or can I assume that everything will work unless otherwise pointed out? Dependencies are handled in the CPAN client (and written by Dist::Zilla), so that should be no problem. (I’d also be interested in whether any omissions mentioned in the POD are design choices or the idea is to add them in the future, and which if so.) HTML documentation support should definitely be added before I'd consider it finished; the others are design choices. That said, I'm not opposed to implementing any of the others if it can be done in a tiny enough way. If I end up adding extensions (which would essentially mean a rewrite of MBT) then even the tininess restriction would be gone for the other ones I guess. On Mon, Aug 29, 2011 at 5:07 PM, David Golden dagol...@cpan.org wrote: for C/XS modules, a lot of libraries are needed to compile the XS, location the C compiler, etc. This is ugly, complicated stuff to get right portably, which is why MBT doesn't do it (yet) I have a prototype tying together ExtUtils::CBuilder and ExtUtils::ParseXS, it only supports simple XS modules and is so far only tested on Linux, but it was pleasantly simple to implement. Eric raises the question why bother and I think for module authors, at least right now, there is no burning platform to switch. Schwern has been trying to get people to stop using EU::MM for years and I think the MBT is a stepping stone towards that vision. Once it figures out the hard bits of interacting with the toolchain, it should be relatively easy for it or successors to add the missing features within a well-defined framework. Yeah, most of all MBT is an experiment. It's proof that writing a Build.PL implementation doesn't have to be all that hard. It's a process of getting the modules out there that make it easier. Being a viable alternative to existing builders is a bonus really. At some point there will be a non-tiny successor that will do everything Module::Build can and more without becoming an monolith. Perl 5.10.1 supports configure_requires and is already unsupported by P5P, though the Perl toolchain maintainers have an informal agreement to support older Perls (5.6 at least, though that may shift to something in the 5.8 series with decent Unicode support before long). Yeah, I think that on the medium timescale 5.8's lack of configure_requires is the main handicap. Fortunately that problem will fix itself if given enough time. Leon
