Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

Journal of jjore (6662)

Tuesday July 10, 2007
03:46 PM

My unauthorized CPAN upload

[ #33772 ]

I took Andy Lester's File::Next module and changed it so that archives are just strange directories. I can now use Andy's nifty ack program directly on a CPAN repository.

Thing is... to share it I uploaded it in the original namespace as a developer version and without asking for his approval first. My thinking is that neither PAUSE nor CPAN are going to index my version because I don't have permissions to the namespace and it's marked as a developer version anyway.

Was this a bad idea? Andy seems to think so - maybe I'll confuse people with my changes. I figure this is a valid model for sharing changes around to other CPAN-folk. Hack on someone else's module, upload it, maybe it gets indexed one day. Probably not though.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I don't see it on unless I go to it directly from ~jjore. It isn't visible from [] or [].
  • I see none. Actually the recent changes to, cause for much groaning and complaining, would seem to encourage this sort of thing precisely for the reason you cite: only someone who is authorised for the namespace can make indexed releases to it.

  • I think it's a good idea that is made confusing by the existing CPAN system. It means that File-Next-1.00_01 (or whatever) shows up in new module uploads, which means a lot of people are likely to see links to it. Does anything else index it? I wonder what happens if Andy now uploads 1.000_01.

    I'd love to see an ease in this sort of concept, but I think that the CPAN makes it end up being confusing.
    • It won't get installed thru the shell, but regardless, it's potentially confusing to people.

      The biggest thing that makes it a bad idea is when the author asks you to take it down. That should end the discussion right there.



      • The biggest thing that makes it a bad idea is when the author asks you to take it down. That should end the discussion right there.

        No it doesn't. You asked me to take it down because it was confusing. I didn't understand why you thought so and since I had a valid reason to have the unauthorized version on CPAN, figured it'd be ok to chat you up and later, thought to chat use.perl up. That's not a conversation killer, I still don't know why you said that.

        My reason for putting the release from my "branch" on

      • If the author takes it down, that makes it something that the author would prefer you not do, which doesn't necessarily make it a bad idea. If I use your tool to do something you don't like, and you ask me not to, that doesn't make it a bad idea.

        It also doesn't end the discussion. I would, in fact, suggest that it *starts* the discussion.

        There is a simple solution to wanting to avoid derivative works: prohibitive licensing.
        • I don't care if he makes a derivative work from File::Next. In fact, that's likely to be the result, based on what I've skimmed in the code. My only objection is that he uploaded his derivative work with the same name.

          If you look at [] there is a link to [] with the text "File-Next-1.00_01". There's nothing to indicate that this is someone other than File::Next's author having uploaded it.

          If it were File::Next::Whatever, I would



          • Yup. In fact, I mentioned that. It's a very good practical indicator that this kind of thing will not work well in the general case until there is some change to namespace ownership.
            • The big issue is really that the changes that JJORE put up are not going to go into File::Next. They're a prototype of what he's proposing I add to File::Next, but I'm not going to put them in. So someone using that one version could come back and say "Hey, I'm using this version, and I upgrade to 1.02, and it broke."

              Yes, I know it says "Developer release", but so what? What does "developer release" mean? There's not some standardized meaning of what that means. What I take that to mean is "This i



              • Right. It would be more interesting to have "private" or "personal" releases or editions, which would not be published the same way. One way to do this is to upload, say, JJORE::File::Find or File::Find::JJORE. The problem there is that things on the CPAN never go away.

                It would be nice to have a way to say, "I am going to send this to the cpan as a proof of concept, like a vendor branch, which can be used in place of the existing, legitimate version."

                Perhaps the simplest way to do this would be to improv
                • Unfortunately, this doesn't really work. If I want to plug some alternate version of a module in then I can't change the namespace. I could could fiddle with the distribution name though, I guess.
                  • Well, you'd employ some small trick like aliasing a class or exporting all your code into the "faked" module. I agree that these suck, hence the Inject solution.

                    Don't worry! FIXED IN CPAN 6!
          • There’s nothing to indicate that this is someone other than File::Next’s author having uploaded it.

            Nothing except the big fat red ** UNAUTHORIZED RELEASE ** when you click the link…

      • Also, just because I don't want to be obnoxious about it, I've asked PAUSE to delete the thing.

        The thing I uploaded is [] and the next version is [].
  • I vote for the interpretation that the unauthorized upload was a cynical and nasty, and of course immoral, attempt to circumvent some dissent (known or anticipated) from the original module's author.

    I certainly wouldn't want it happening to my modules.

    As other have pointed out, what was wrong with 'use base...'?
    • Are you being sarcastic? I can't tell. I'd talked with Andy about these changes some months in the path. I have little reason to think it can't be merged in.

      Of course... if they can't be merged I need a pretty good reason. The pain of forking two distributions at once is fairly daunting.