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.
  • It seems that being a Perler does not shield you from the hated that people have for Windows. I recently asked for a module to support Windows and the author put a rant in the change log about how effed up it is. He is doing it, I guess because he wants to support someone using Perl, but he does not like the fact that he has to.
    • As long as he only rants in the changelog but doesn’t refuse to consider the request, I can fully sympathise. Proc::Fork (which I’m herding) causes Perl on Windows to segfault, and I have absolutely no idea how to fix it. I tried a bunch of things and got nowhere, and no one else seems to have any useful suggestions.

      So I can well understand it if people rant in frustration about Windows. (Or for that matter, about any other part of the environment; Unix is generally saner, but it too is softwa

      • So I can well understand it if people rant in frustration about Windows.

        Also, it's not as if there's a legion of Windows Perlers providing patches for these issues. I've asked for several and received approximately none.

        I can't support a platform I don't use, and there's little point in trying to support a platform if its users don't care enough to help.

        • It isn’t even at that point for me. I do have a Windows box to test on now, at least. (That wasn’t the case half a year ago.) Unfortunately that didn’t help – I might have the tools necessary to support the platform, but I still don’t know how to do it. I tried everything I could think of, but none of it worked. At this point there is nothing left I can do but say “Windows is unsupported; patches welcome.”

          Oh, and rant in frustration in the Changelog.

  • Alias,

    I agree that Perl modules should be easy to install, even by non Perl people.

    Today I'm slogging through an install of the SocialText open source wiki. It's in Perl, and depends on about 100 perl modules (literally, I think).

    It's taking hours to install, and needs some advanced skill to workaround the oddities coming up.

    And of course, there's a great chance that the Perl modules I end up installing are not exactly the same as the developers have tested with.

    This is a different ease-of-installation than
    • There's two seperate issues here.

      One is the dependency explosion. That is actually not so big a deal as long as all the modules install cleanly on all platforms, and don't have options or ask questions.

      Yes it does become a problem when the dependency trees get large though, as a percentage of them will ask funny questions or potentially hit problems.

      Good managers of these large projects will try to choose dependencies that are relatively light, and will also put effort into caring for their upstream, patchi
  • I always thought that the security modules were developed far enough to get the ancillary task done, and no further.

    I don't think that's necessarily a bad thing. A lot of modules start like that. It's just that the security ones stopped moving forward. :)
    • ya

      It sort of seems like someone told them "Make it Work, then Make it Maintainable, then Make if Fast" and they stopped at the first one.
  • I don't know which author you're referring to, but that "winblows" attitude is awful. If you need that added layer of protection (and it seems reasonable), what are the odds of forking the module, ignoring the original author and switching to the fork? I hate suggesting that, but I can't think of an option other than "take the module away" and I would be horrified at the latter thought.

    • I think that there are many reasons why one could dislike Windows, and for those very reasons one would avoid spending effort/time in supporting that platform. This is something that happens all the time in many other fields, and not necessarily in the "Windows" direction - just think about the support for Linux of "mainstream software" like skype.

      Ranting and denying any type of support is probably a shortminded reaction, but I think that we should respect the decision of someone to *not* support something
      • Normally this might not be a problem.

        But the crypto modules impact everything.

        The result is "If you use security modules, you lose windows support".

        CPAN cares more about platform-compatibility than it does about security. Better that it work at all than work securely.

        Because of one single developer deciding he doesn't like windows, now nobody gets to have secure CPAN by default.

        All limitations imposed by an individual impact EVERYONE in your dependency chain.
        • I agree with you completely, and this is the very reason why a fork is not only justified, but necessary. Just to avoid being hostage of a single.

          Probably, the situation could be though as if one had to implement those modules from the scratch, but having a working reference implementation already available :)
    • It's not me that needs the module. This is always the problem.

      The Module is depended on by Module::Signature, via OpenGPG, via 3 or 4 more layers of recursion.

      It's a case of a few bad eggs ruining it for everyone.
  • Oh how I've struggled to install Net::SSH::Perl on Solaris because of dependencies failing to install. I'm looking at *you* Math::Pari [cpan.org] . Out of any module I've ever installed, Net::SSH::Perl is by far the most difficult to get up and running.
    • Net::SSH::Perl is one of the better modules that eventually hits all the dependencies that cause problems.