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.
  • A while back I speculated on the various proposals for a "CPAN Replacement" I saw and mentioned that it appeared to me that there was a lack of planning.

    Mark asked me to not comment on CPAN6 until after the release at YAPC::EU and gave me an early copy of the paper, and I've happily done so.

    But reading through the final version of the paper, some concerns remain.

    Without wanting to get too much into specifics, I was wondering how you plan to deal with this type of thing. I see a lot of detail on what your solution looks like, but not so much detail on things like the underlying reason for it's existance, use cases, constraints, assumptions, priorities, and so on and so forth.

    How do you plan to deal with these sorts of issues that are likely to be brought up by a number of people regarding any design that would claim to replace the CPAN (and yes I'm aware that CPAN6 isn't actually a sequel to the CPAN and is more a meta-repository concept), and how willing are you to change the design (possibly significantly) in response to them. Because so far the impression from this side of the internet is of a grand design unveiled in one go, and a rallying cry to go build it, when only a relatively small number of people have seen or been involved in the design.

    The CPAN is very large and very complex, and replacing it isn't going to be as simple as we might think. I honestly cannot think of anybody involved in the existing CPAN that is qualified to design a complete replacement for the CPAN, and I'd really like to see a lot more work done on some fundamentals like what EXACTLY our priorities should be for the 6PAN or CPAN6 or whatever it gets called, and have a design vetted by as many people as possible, and able to stand up to the criticism of all and sundry, before we start talking about building it.

    Comments?
    • The CPAN is very large and very complex, and replacing it isn't going to be as simple as we might think.

      Not true. The CPAN is rather small by today's standards and very simple. Clearly, you've not read the Zen paper describing the mechanics of it in very simple, straighforward terms. You are correct in supposing that it will not be simple to replace, but likely not for the right reasons. Anyone can build an ftp archive, put it on the net and open it for business. What makes CPAN work is not to be foun

      • My concern for this project is that clearly little research was done into what has been done in the past (e.g. that we had already agreed to Audrey's request to make a 6pan repos on the existing CPAN)

        While this was news to us, and our research did not uncover this - nor did any of the people at YAPC::Europe mention this to us - the efforts need not conflict; I hope they can re-inforce one another.

        CPAN is about the only thing keeping a lot of users of perl around and introducing a P6-like CPAN archive

        • This is a confusing assertion. Why would users care if another system is being built to replace it, especially if we are extremely careful not to switch the old one off for several years? It will be giving them only more options.

          Because if the same sort of design and implementation limbo that now exists with P6 with P5 more or less moribund, is introduced to CPAN, it has the potential to finally push away those who are already on the fence. One being dead and one not being implemented with far too many

          • Simpler approaches to the distribution problem are already under development, in competing projects such as 6pan. I wish them the best of luck and hope in turn to be able to be of benefit to them. Perhaps someone could follow-up with the link? I feel a bit shouted down with the way these comments work.
            • 6PAN is a competing project? *sigh*
            • Personally, I think that competing Perl repositories will only make matters worse. One of the reasons why CPAN is successful is that it is *the* place to turn to for Perl modules.

              Other than that, I won't repeat Elaine's, Adam's and brian's points because I agree with them. I think the three of you disagree much less than Elaine stated anyway.

              Steffen
      • > What makes CPAN work is not to be found in the software.

        And that is exactly what I mean.

        "CPAN" as an FTP archive is a non-issue, the actual distribution part is the simplest and most trivial part.

        What makes it successful is indeed due in big part to the social parts of the system, and those are the very things that a notional replacement design would have to take into account.

        > Uh, because they just...did it...instead of talking it over and taking 6+ years to design the ultimate archive?

        Who did? Var
    • I see a lot of detail on what your solution looks like, but not so much detail on things like the underlying reason for it's existance, use cases, constraints, assumptions, priorities, and so on and so forth.

      The "Emerging problems" section of the Global Design Document [cpan6.org] cover a lot of the shortcomings of the current CPAN. Also see the section "Projects" in the chapter "Pause6 Organization" for some more examples.

      How do you plan to deal with these sorts of issues ... and how willing are you to change

      • The setup you have there makes it really hard...

        I'm already on a billion mailing lists, unless you plan to have it go onto nntp.perl.org I really don't want to be on two more.

        I don't know how I'm supposed to generate patches to a postscript file (why isn't everyhing just text or HTML) and in any case, I'm useless with patches, and so is Windows.

        Not to mention I can't actually read the postscript file on this system.

        OK, I may be bitching here, but if 90% of the computer users can't play nicely without projec
        • I agree with Adam. I'm not sure how you selected Jarkko and Adam to be the early reviewers of the paper, but it seems to me that Andreas might have something good to say, and that the current PAUSE admins might have had a lot of wisdom to add. My first inkling that anything was happening is when someone subscribed me to the CPAN6 mailing lists. I suppose that's a nice jesture, but no personal note accompanied the subscriptions, and I promptly unsubscribed. I don't do mailing lists. Put it on nntp.perl.org a
          • I'm not sure how you selected Jarkko and Adam to be the early reviewers of the paper, but it seems to me that Andreas might have something good to say,

            Mark has been in contact with Andreas along the way.

            ... and that the current PAUSE admins might have had a lot of wisdom to add.

            We basically sent it to the people who asked for it. We have taken the initial design, subjected it to review and now we are asking the wider community for input. There's no point in releasing something before it is ready

        • And if you do not wish to send patches, you don't need to. Just raise issues like you have done.