gistfile1.txt

08:00 < dam> ingydotnet: ready to take some flac for inventing Module::Install? :)
09:42 < ingydotnet> dam: sure. what you got?
09:43 < ingydotnet> ansgar: ta
09:44 < ingydotnet> dam: M:I is going to be the best thing that ever happened to debian-perl :)
10:42 < dam> ingydotnet: it is a virus spreading around, not a library line every other dist.
10:44 < dam> also, the spread part lacks copyright/license notices, so we have to assume things
10:51 < dam> enough ranting, it is not a suitable welcome anyway.  :)
18:01 < ingydotnet> hi dam 
18:01 < ingydotnet> dam: not a very long rant :)
18:03 < ingydotnet> dam: from my perceptions so far, I am wondering how familiar you are with META.yml/json files
18:03 < ingydotnet> every modern dist has one
18:04 < ingydotnet> M:I builds them by default, as do M:B (and even EU:MM I think)
18:05 < ingydotnet> they have are a hash with much of the info debian needs
18:06 < ingydotnet> I notice you don't use it for email address, which I find completely surprising
18:06 < ingydotnet> but also there is a license entry
18:07 < ingydotnet> that seems like what you want for copyright
18:07 < ingydotnet>  
18:08 < ingydotnet> also M:I is not viral. It is a Perl module packaged like any other.
18:09 < ingydotnet> it attaches fixed/extra packaging functionality (over EU:MM) into a dist, but never installs that functionality.
18:10 < ingydotnet> it allows Perl authors to stay modern, using bleading edge technology, without requiring the entire massive tool chain to catch up.
18:11 < ingydotnet> and if an idea is bad, it fails fast without poisoning the well, as it were
18:11 < ingydotnet> ...
18:12 < ingydotnet> (... is yaml for </rant> :)
18:13 < gregoa> ingydotnet: lib/DhMakePerl/Command/Packaging.pm uses META.yml (though not META.json - d'oh) for finding various informations
18:13 < gregoa> ingydotnet: the "viral" part dam referred to is about copying stuff to inc/
18:15 < gregoa> ingydotnet: I'm sure dh-make-perl could be more clever to find out stuff. it has a long history, and parts of that are still visible :) (although dam has rewritten large parts)
18:15 < gregoa> ingydotnet: any help on dh-make-perl is highly appreciated! there are some bugs, and there's a TODO file with some ideas, so feel free to jump in :)
18:49 < ingydotnet> gregoa: thanks!
18:51 < ingydotnet> gregoa: I'm not sure this is news to you, but copying stuff into inc/ is completely non viral. In the sense that M:I and its plugins are never installed as part of another dist.
18:52 < ingydotnet> A good way to think of it is that inc is just a place to but build time helper code, and M:I automates that
18:54 < ingydotnet> M:I has accumulated its share of problems over the last 10 years though
18:54 < ingydotnet> that's why I recently started Module::Package
18:55 < ingydotnet> It's a brand new wrapper around M:I. It's been out a couple weeks now. I have about 10 modules out using it right now.
18:55 < bremner> from a distro point of view it is desirable to minimize how many copies of a given piece of code exist.
18:55 < ingydotnet> Every Makefile.PL using it is the same one line:
18:56 < ingydotnet> use inc::Module::Package 'Ingy:modern 0.07';
18:56 < ingydotnet> bremner: I agree
18:57 < ingydotnet> bremner: that is one concern
18:58 < ingydotnet> bremner: balanced against functionality. as stuff that M:I does becomes part of the standard toolchain, it can be pulled from MI
18:58 < ingydotnet> bremner: from a modern computing POV, it is usually ok to trade a little disk for other big wins
18:58 < ingydotnet> ...
18:59 < bremner> its not about disk space, its about security and other fixes
19:00 < bremner> I'm too much a novice perl author to argue the tradeoffs, I'm just explaining the reaction from Debian people to making lots of copies.
19:01  * bremner &
19:02 < ingydotnet> it's a two edged sword. you can depend on the toolchain, or depend on the author. M:I can get secutiry fixes out much faster than the toolchain. but it depends on the author releasing.
19:03 < ingydotnet> both sides need to be responsive
19:03 < ingydotnet> but before M:I there was no 2 sides
19:03 < ingydotnet> M:I gave Perl authors the chance to move into the future faster than the toolchain
19:03 < ingydotnet> and this really helped push the toolchain
19:04 < ingydotnet> so its a win/win
19:04 < ingydotnet> with a little bit of lose ;)
19:05 < ingydotnet>  
19:06 < ingydotnet> with M:P, I'll soon have 'make debian' available to all my modules.
19:06 < ingydotnet> that will push on both the toolchain community and the debian-perl community :)
19:07 < ingydotnet> fwiw, toolchain is the CPAN term for all the packaging tools. #toolchain on irc.perl.org
02:45 < dam> ingydotnet: I will pick the viral/license point first. Thing is, Debian distributes sources in addition to binary packages (.deb). So we appreciate clear copyright/licensing of each and every file found in a CPAN distribution. Considering the source part, M:I is really viral.
02:48 < dam> ingydotnet: about the non-toolchain code can move faster, I agree, but don't understand why integrating with distributions is necessary. Can't M:I be used like any other module? Yes, it mecomes a prerequisite, but is this really an issue? cpan install Module::Install is not that hard to figure out. Another difficulty may be providing stable interfaces. We have an example in debian for a similar tool with similar problems.
02:49 < dam> It is called debhelper and eases a great deal of package creation particularities. It's interface is strictly documented and predictable. Whenever a change is made that is not backwards-compatible, that change is in effect only if the 'client' declares that it can handle the respective 'compatibility level'. Works like a charm and is rock solid.
02:51 < dam> If only M:I becomes something that authors can 'use' in Makefile.PL without it being copied to inc/ I'd say all the rants are gone and forgotten :)
05:53 < ingydotnet> o/
05:53 < ingydotnet> hi dam
05:58 < ingydotnet> dam: I can't really agree with you that M:I is viral in any sense. I could hand copy all the code into inc/ like I suspect that dh-make-prel does with privinc/My/Builder.pm
05:58 < ingydotnet> M:I just automates this for me
05:59 < bremner> dh-make-perl copies code in? That's news to me.
06:00 < bremner> that doesn't mean it isn't so, just that I never knew it.
06:00 < ingydotnet> bremner: it ships code that could be prereqed
06:00 < ingydotnet> it doesn't copy in code, it just ships a packaging tool
06:00 < ingydotnet> M:I modules do this automatically
06:01 < gregoa> ingydotnet: the problem IMO is that it also copies bugs, and the can't be fixed in just one place due to the copies. M::I 0.85 had an annoying bug where it ignored --skipdeps for PERL_AUTOINSTALL in M::AutoInstall. no big deal, a little regression and fixed quickly upstream. but: the buggy version was not only around in tons of other modules in inc/, there were even authors who _upgraded_ later to exactly the broken version
06:02 < ingydotnet> gregoa: like I said before, getting fixes to everyone can happen 2 different ways. M:I actually makes it easier for authors to get out a patched toolchain
06:04 < ingydotnet> M:I does rely on the author paying attention, rather than the whole world paying attention. So I think things can go either way.
06:04 < gregoa> ingydotnet: obviously, as we learned in this case, not all of them do it. and from a distribution point of view it's much more desirable to have a fix in exactly one place than waiting for dozens of people to fix it (or do it ourselves a dozen times)
06:05 < gregoa> ingydotnet: I see your point, I just want to explain why we are not fans of the M::I behaviour
06:06 < ingydotnet> gregoa: with all due respect, my impression of getting changes to market, through debian channels is that it's not speedy. (I also see your points :)
06:07 < ingydotnet> we had the same problem with the CPAN toolchain 10 years ago
06:07 < ingydotnet> and that was the impetous for M:I (mostly)
06:08 < gregoa> ingydotnet: regarding debian it always depends if you look at stable or unstable :)
06:08 < ingydotnet> another impetous was that Makefile.PL used to be a black art with no code reuse
06:09 < ingydotnet> gregoa: ok, I'm a total newb to downstream. I'lll take your word for that, for now.
06:09 < gregoa> ingydotnet: BTW: I sent a reply to the list yesterday, not sure if you're subscribed already, and I haven't CC'd you. in case you missed it: http://lists.debian.org/debian-perl/2011/06/msg00013.html
06:09 < bremner> even if you could convince us, Debian at large would still be a tough sell...
06:10 < ingydotnet> a tough sell for what?
06:10 < ingydotnet> does M:I modules never make it to Debian?
06:10 < gregoa> ingydotnet: and having these discussions where we can combine upstream and downstream experiences can only be helpful for both sides
06:10 < ingydotnet> gregoa++
06:11 < bremner> a tough sell that the advantages of including more of the build system with each package outweigh the disadvantages. No of course no-one is talking about banning M::I, people are just explaining why this bias against copying exists.
06:13 -!- AzaToth [[email protected]] has joined #debian-perl
06:14 < ingydotnet> think of M:I this way... once upon a time there were Makefile.PLs that were 100 lines or more long. They did all this stuff by hand. M:I took all those things and moved them into files, and decided which files needed to be included. Makefile.PLs became 5-10 lines. All the same code was being shipped, but now it was organized.
06:14 < ingydotnet> If you look at it that way, it seems really smart. Even to a DD ;)
06:16 < ingydotnet> anyway, it's good for you guys to challenge me on this.
06:18  * ingydotnet me goes back to releasing 10 modules today, including 4 new ones :D
06:46 < dam> ingydotnet: nice try with dh-make-perl's privinc/My/Builder.pm, but that is used only by dh-make-perl's build system (it is a M:B subclass), not shipped/copied/propagated anywhere else :). I still don't see the reason why M:I must be present in using dostribution's inc/. Why can't it live in @INC instead?
06:51 < ingydotnet> dam: privinc is bundled in your dist
06:52 < ingydotnet> it has to be to run Build.PL user side
06:53 < ingydotnet> dam: you seem to think that inc/ modules are somehow different
06:53 < ingydotnet> but they aren't
06:55 < ingydotnet> dam: anyway I hope you read the rest of what I wrote about M:I
06:56 < dam> ingydotnet: there is a misunderstanding here, but it seems I can't explain it
06:56 < ingydotnet> seems it
06:56  * dam reads all backlogs
06:56 < ingydotnet> cool
06:57 < ingydotnet> it is the point to try to keep M:I plugins to a minimum, but to also be able to use newer code that hasn't been tested in the wild but is known to work for the author.
06:58 < ingydotnet> I understand your pov. it's easy to have that pov when you see it from the current state, rather from the whole evolution
06:59 < ingydotnet> I'm sure you know what I mean :)
06:59 < ingydotnet> (I'm sure dh-make-perl gets similar rants)
07:01 < ingydotnet> audrey and I were the ones who took it from chaos to order way back when. I'm not particularly happy about it's state today.
07:01 < ingydotnet> adamk is great, but he just keeps it working...
07:02 < ingydotnet> I have come back recently, and taken M:I to a new level with Module::Package
07:03 < ingydotnet> from one POV it makes things even crazier (If one line Makefile.PLs scare you :)
07:03 < ingydotnet> on the other hand, it really reduces unecessary bloat in MI dist
07:03 < ingydotnet> M:I dists
07:05 < ingydotnet> so things are moving towards leaner. But it's weird to me that people can be fussed about orderly code in a inc/ dir, but completely fine with a 300 line Makefile.PL
07:05 < ingydotnet> ...
07:06 < dam> depends on what you do with that code :) we don't maintain it. we (1) ensure we are legally allowed to distribute it and (2) run it
07:07 < dam> so we don't really care how ugly Makefile.PL is, authors do. And I guess this helped M:I spread
07:08 < ansgar> ingydotnet: I remember M::I strips all comments from files in inc/, including copyright notices, including those that say that copyright notices must be preserved...
07:09 < ingydotnet> all M:I did was put the copy/pasted tricks of Makefile.PL into order.
07:09 < dam> innovation is all good, as are early adopters of experimental features. what my rant is about is that leads to shipping M:I within other distributions. It can't be so hard to provide stable and experimental interfaces via a module in @INC...
07:09 < ingydotnet> ansgar: file a bug. 
07:10 -!- Dom [[email protected]] has left #debian-perl []
07:11 < dam> there is a tradition in the Ruby world to bundle your application with all the external modules it needs, because newer version of them may break the application. I hope M:I isn't water in such a mill :)
07:11 < ingydotnet> dam: M:I has only recently come to a stable API
07:11 < ingydotnet> M:I is not about that at all
07:12 < dam> *relief*  :)
07:12 < ingydotnet> nothing in inc is a runtime dep
07:12 < ingydotnet> period
07:13 < ingydotnet> they are build time helpers like your privinc
07:13 < ingydotnet> you could have inlined that class in Build.PL
07:13 < dam> written by and maintained someone else
07:13 < ingydotnet> as are all M:I's
07:15 < ingydotnet> I really need to release 7 modules now...
07:17 < dam> sure, a rainy sunday is just the right time for that (or some ranting)  :)
07:20 < ingydotnet> dam: 6 releases to go. Look at https://gist.github.com/1008993 especially the top and bottom.
07:25 < ingydotnet> 3 releases to go