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

use Perl Log In

Log In

[ Create a new account ]

grink (8549)

grink
  (email not shown publicly)

Journal of grink (8549)

Saturday August 09, 2008
07:19 PM

CPAN: Where is the source repository for $DIST?

[ #37141 ]

Something that would be nice to have:

The ability to embed a link to the project's source repository so that search.cpan.org could display it.

You can do this by sticking something in the POD, but having it in a standard place (like Links:) would be much, much better:

    * You could find the project's repository without hunting through the POD
    * You could tell, at a glance, if a project has a repository that the author would like to share
    * It would encourage users to contribute documentation and bug fixes

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 is even official [sourceforge.net].

    And in your Module::Build->new() arguments:

        meta_merge => {
            resources => {
                repository => 'http://...',
            },
        },

    I could say something about svn4cpan, but oh well...

    • I could say something about svn4cpan, but oh well...

      Good thing you didn't say anything: it made me curious enough to go take a gander at http://scratchcomputing.com/svn4cpan/ [scratchcomputing.com]. :-) Very interesting... Have you taken a look at Github recently? They have a system that is very close to what I think you're striving for. The network view of project repositories (e.g. http://github.com/andychilton/cil/network [github.com]), in particular, is a thing of beauty.

      • Very interesting... Have you taken a look at Github recently? They have a system that is very close to what I think you're striving for.

        Github is interesting, but I don't think it really captures what I was going for with svn4cpan. (They do seem to have addressed some of the discoverability issues of git hosting, but their interface is still pretty noisy.)

        What I thought was important about creating a repository tree around CPAN was the notion of using the http namespace (and proxying) to create a uniform addressing (like a DNS for code), including the trunk, tags, branches -- regardless of where you were hosting. It would basically have t

        • What does SVN offer for this that git doesn’t? Can you explain?

          • What does SVN offer for this that git doesn’t? Can you explain?

            Apparently not.

                1. A simple web view: browseable url is the same as the checkout url, clicking on the filename downloads the file. These might be nits, but IMO they are a barrier to discoverability. Yes, I could build/install/whatever a view that does what I want, but a) we already established that I don't have the time and b) a GET on the .git file must return the file, right?

                2. The svn client is already installed or easily installable, and not strictly necessary anyway (s

          • What does SVN offer for this that git doesn’t?

            One argument that I can see for subversion: git clients can deal with svn repositories, but not the other way around -- so if you want to make the system accessible by a maximum of people, a svn repository is the way to go.

          • What does git offer in this case that SVN doesn't? The value of svn4cpan isn't "Hooray, let's create yet another hosting service for a fraction of the world to use, isn't this great!" but rather using directory versioning software to keep a history of all of the public releases on CPAN under version control.

            A distributed version control system isn't at all interesting because you're not going to fork CPAN history. That doesn't even make sense, at least not without a working time machine (and if you have a

        • What I thought was important about creating a repository tree around CPAN was the notion of using the http namespace (and proxying) to create a uniform addressing (like a DNS for code), including the trunk, tags, branches -- regardless of where you were hosting. [..] Git is, of course, a beautiful solution to the wrong problem in this case, so whatever -- what you have now is tarballs and now it is going to stay that way for the conceivable future.

          First, only now do I realize that you probably had someon

          • something about Git every single step ... forkstab ... eyeball ...

            Well, only recently. Nobody said much about git in early 2006.

            My goal was merely to point out a possible way to deal with social programing that I find quite nifty and see what you think of it

            Like I said, "interesting", but I don't immediately see it being useful to CPAN. We currently have the META.yml key (which started this thread) for discovery of repositories, and everyone using it will improve things. For now though, the existence of github just means that the landscape of repositories for CPAN modules will splinter more than it already was (it used to be that you would find the repository on sourceforge or perl.org or the aut

  • WriteMakefile accepts a EXTRA_META argument that just get appended to the end of the generated META.yml so you can use it as for example:

    EXTRA_META => q{
    resources:
        repository: svn://svn.versed.se/public/Perl/modules/JavaScript
    },

    • Eric, Alias, & claes

      This is good stuff. It's great that there's already a convention for it.

      Maybe a bookmarklet or greasmonkey script could bring this feature to the forefront.

      • Ask, and thou shalt receive: http://userscripts.org/scripts/show/31660 [userscripts.org]. Enjoy! :-)

        • Wow, that's frickin' sweet!

          I made /repository:\s+(\S+)/ case insensitive by adding the /i at the end: /repository:\s+(\S+)/i

          Cheers

          • Wow, that's frickin' sweet!

            *g* Thanks.

            [ //i ]

            Not a bad idea. I'll add it to the next iteration of the script!

          • From my reading, 'repository' is an official key in the standard, so shouldn't need to be case insensitive. Are there dists using 'Repository'?

            • Yes, Alias's example has 'Repository' instead of 'repository'

              http://search.cpan.org/dist/ack/ [cpan.org]

              As for being an official key, that may be true, but I can't think of a good case where TPTB would want to differentiate between a Repository: or repository: or rEpOsitOry: or whatever (so case insensitivity shouldn't hurt).

              • Hmm, either Andy was ahead of his time or not reading carefully enough.

                As for being an official key, that may be true, but I can't think of a good case ... so case insensitivity shouldn't hurt.

                Well, hash-lookups are case sensitive. If we're going to get into a case-insensitive-preserving behavior with META.yml, that could get frustrating really quick. And generally, with regard to standards: "couldn't hurt" ... will.

                • You're right, a hash lookup would be problematic.
                  Maybe we can help people out by issuing warnings about their META. Some things that could help:

                      1. A META validator
                      2. A standard way of generating META during the dist build/ship process

                  • 1. A META validator

                    That would make a fine cpan module... possibly a kwalitee point?

                    2. A standard way of generating META during the dist build/ship process

                    Well, M::B already does a lot of that. I suppose it either needs to provide validation on the meta_merge or a nicer way to specify such things (extracted from standard sections in the pod would be nice too.)