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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Sometimes packages die from a more conceptual point of view, because they are implemented based on an incorrect premise... These can often be fixed, if often reluctantly (*cough* Module::Build and PREFIX *cough*) :)

    "Incorrect premise" is about the nicest thing anyone can say about PREFIX. If you were going for accuracy, you might have said "Why would anyone have ever thought this could possibly work correctly?"

    • I think the problem with Module::Build and PREFIX was two-fold though.

      Firstly, PREFIX was implemented on a completely incorrect premise.

      But the secondary problem was the believe by Module::Build that they could utterly break compatibility with PREFIX and then document their way past it because they were right.
      • You say that as if you believed that it were possible to be compatible with PREFIX. Given that even Schwern believes that the feature just plain doesn't work, how in the world would the M::B developers ever satisfy you? If they made it do what everyone seems to think it does, they've broken compatibility with it. If they somehow magically made it do what it actually does, they get complaints that it doesn't work the way everyone thinks it does.

        If you're suggesting that the only sane approach was not to

        • I'm suggesting that the toolchain is a single entity.

          You can't just invent entirely new standards and make half a dependency chain act differently to the other half of the toolchain. It breaks the entire

          So either Module::Build [cpan.org] should be bug-compatible with the way that PREFIX works, or the Module::Build people should have worked with the rest of the toolchain to deprecate the entire feature across the entire thing, while leading a suitable replacement that required no increase in work from the user.

          A signif
          • All this while I thought the important half of the phrase "backwards compatibility" was "compatibility".

            If the "whole toolchain" really is a single entity, then we ought to consider MakeMaker severely broken on platforms that don't include a working make utility. Should M::B not work on those platforms, for the sake of backwards?

            • Backwards is entirely orthogonal to compatibility.

              I just find it a shame that in trying to not be backwards, the initial choice was to also not be compatible.

              Adam K
              • I really can't see how it's possible to be compatible with a feature as broken as PREFIX. If you support it as it worked in EU::MM, then you surprise everyone who expects it to do something sane instead of spewing files randomly over the filesystem. If you make it work so that it does something sane, it doesn't work the same way that EU::MM does.

                Please enlighten me.

  • Just to expand on my previous comment...if a person is the author/maintainer/whatever of an open source project, there are ways to learn a little bit about folks who offer to help with your project. One could look at posts to sites with content related to your project(Perlmonks, for example), anything that they've posted to Sourceforge, bug reporting sites, and mailing lists. So you can see what your prospective volunteer has done, which could alleviate concerns about giving up a little bit of the creati
  • I appreciate your perspective, as well as the restrained delivery.
  • I've found that it's a pain to find mentions of the URL your SVN repository is at. It's nice once I've gone to the work of 15 minutes googling to get the URL but prior to that, it's painful. Mind fixing that? A pointer on ali.as might be nice.