Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Do you need to upgrade your Module::Install? 18 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ... Module::Build doesn't have a method for ensuring users upgrade.
    use Module::Build '0.xx';

    Alternately, stick the dependency in build_requires.

    • use Module::Build '0.xx';

      As far as I'm aware, that doesn't ensure that Module::Build is upgraded, it just crashes the installer with an obscure error message that will be buried somewhere in the middle of 3000 lines of CPAN.pm output.

      If you are doing a one-off install and running Build.PL directly, and you understand error messages, then maybe in that small case it's good enough. but of course almost nobody does that.

      As for the build_requires dependency, the Build.PL needs to be run in order to confirm that

      • I don't have a distribution with a custom Module::Build subclass where the build_requires trick won't work, but if the use line doesn't, how about printing the same error message? M::B and CPAN.pm communicate somehow, so I see no reason why following that protocol won't make this scheme work.

        • The continuing problem is that error messages are of no real use.

          There's a fairly good chance that the user will never see it, being buried deep in a larger installation.

          Any solution which involves wetware (the user having to think) is no solution at all.

          "M::B and CPAN.pm communicate somehow, so I see no reason why following that protocol won't make this scheme work."

          As I said, Module::Build hasn't solved this problem yet.

          The solution, as I've mentioned before, requires CPAN clients to have the capability t

          • You are not paying attention. Let me explain very slowly.

            CPAN.pm and CPANPLUS both somehow detect when a distribution has unfulfilled dependencies. Both offer to install those dependencies.

            Both MakeMaker and Module::Build somehow indicate unfulfilled dependencies to the installer. I don't know if it's screenscraping or an API or whatever. I skimmed CPAN.pm this morning, but couldn't find it in two minutes.

            Now if there's an API or if there's a particular error message being scraped and detected and

            • You are not paying attention. Let me explain very slowly.

              There are three different conceptual code elements involved in a distribution.

              The Installer.

              The Build Process.

              The Installed Module.

              CPAN.pm detects the Installed Module has unfulfilled dependencies, and is informed of them by executing the installer.

              This can theoretically be shortcut for static dependencies in a setset of cases, but in practice nobody ever sets that flag and so the installer MUST be run.

              CPAN.pm detects the Build Process has unfulfilled
              • That should read...

                "This can theoretically shortcut for static dependencies in a subset of cases"

              • ...but in practice nobody ever sets that flag...

                I am suggesting that, in those cases where the installation program depends on a specific minimum version of the installer module (and in several years of maintaining a couple of dozen of publicly available modules, I can think of one case where this was necessary), the author should do precisely that.

                There already exists a perfectly good mechanism to mark and install dependencies through both of the installer shells. Why complicate the process?

                I can

                • I am suggesting that, in those cases where the installation program depends on a specific minimum version of the installer module (and in several years of maintaining a couple of dozen of publicly available modules, I can think of one case where this was necessary), the author should do precisely that.

                  That is certainly an acceptable partial solution for the cases where dependencies are static, and one that individual authors can use today.

                  However, unfortunately, not all dependencies are static, and there is

                  • I'm still not sure I've explained myself well.

                    I mean, "Authors of distributions that rely on a specific version of the bundling module should be able to mark that dependency in such a way that the installer can detect that dependency immediately." Whether that means adding a new entry in META.yml or running a little bit of code at the start of Build.PL or Makefile.PL, I don't particularly care.

                    The latter seems easiest.

                    The point is, I believe you can run just enough of the bundling program to flag an

                    • Again, I do agree with you.

                      There SHOULD be a way of doing it :)

                      I can see a number of ways in which it could be done, a few of which you have described.

                      It's just that the situation remains that despite what should be possible, it still hasn't been written, and what I try to keep pointing out is that there needs to be, and that whatever the solution is, it needs to be completed and working before we can consider M:B to be stable and suitable for the core.

                      The fact that Module::Build is in the core is what I wo

                    • That is all reasonable; I quite agree.

                      Is the best place to discuss this on p5p or at a BOF somewhere?

                    • I would think this could get lost amidst p5p traffic. How about the perl.qa mailing list? Various related issues have been discussed there in the recent past.

                      By the way, I'm glad the two of you agree now. I was really waiting for you (two) to realize you were not even contradicting each other. :)

                      Steffen

    • Even users only need to upgrade their M::B when they’re about to install something. And CPAN.pm could check if there is an upgrade to M::B and suggest doing it just like what it already does for updates to itself.

      Seems much more tenable than the M::I model to me.

      I mean, look at that list – good luck getting all 83 authors to push out 469 new releases total, just to fix their installers. And that’s now that M::I is relatively new – what will the situation look like when the CPAN i

      • How are the user's supposed to know to upgrade Module::Build.

        Installers should always assume the user is completely clueless, or doesn't even exist because they've been replaced by a small shell script.

        Yes, CPAN.pm could check and force-upgrade. I've had this conversation with Ken, and there's an RT ticket in the CPAN.pm queue that says "auto-upgrade a specific set of named modules". But it DOESN'T.

        And no amount of handwaving about how other people (users or Andreas) could fix Module::Build's problem doesn'
        • How are the user's supposed to know to upgrade Module::Build.

          If only there were some way CPAN or CPANPLUS could know about dependencies during an installation... yeah, that'd be SWEET.

          • I find that not only a cheap shot, but a rediculous statement coming from somebody that doesn't actually know how the mechanism by which CPAN learns about dependencies during an installation. Both of them.

            Until you learn how the Perl installation process works, it's pointless to continue this too and fro.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.