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
It is even official.
And in your Module::Build->new() arguments:
meta_merge => {
resources => {
repository => 'http://...',
},
},
I could say something about svn4cpan, but oh well...
Re:META.yml resources = {repository = ...}
Yanick on 2008-08-11T22:27:58
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/.
:-) 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), in particular, is a thing of beauty. hub hub
Eric Wilhelm on 2008-08-11T23:20:36
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 turned what is currently a possibly frustrating search into a simple lookup/dispatch. Git complicates things, because PAUSE and svn are basically analogous, and everybody has an svn client, yet a lot of comments have panned the idea of building it out of svn because "git is cooler." 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.
So, historical view of CPAN, automatic tags, ready-to-use repository for all of you PAUSE authors, (author) discoverable forks, pod branches, cross-platform smoke test triggers, list/feed notifications, universal repository discovery, etc. Nope. Tarballs.
I'm convinced at this point that svn4cpan will not happen anytime soon because I don't have the time for it and nobody seems interested enough to back it (after 3 rewrites/tries for a TPF grant.) You could do it in pieces I guess, but I don't know how it will all get tied together.
Of course, when I started this git was but a gleam in Linus's eye, so maybe building it out of git will be practical in a couple more years at which point something else will be the cool new thing and it again won't get any support.
Re:hub hub
Aristotle on 2008-08-11T23:47:33
What does SVN offer for this that git doesn’t? Can you explain?
Re:hub hub
Eric Wilhelm on 2008-08-12T00:02:42
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 (see #1.)
So, what does git offer (for this use case) that svn doesn't? Anyway, I give up. If you are going to build it, use git.
Re:hub hub
Aristotle on 2008-08-12T08:40:32
Huh? I asked a question, I didn’t claim git was better.
Re:hub hub
Eric Wilhelm on 2008-08-12T16:31:23
Sorry, "Can't you just
...?" questions are like that. Re:hub hub
Yanick on 2008-08-12T16:05:02
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.
Re:hub hub
chromatic on 2008-08-12T20:47:08
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 working time machine, you really ought to have better things to do than to change who uploaded what to PAUSE when).
Re:hub hub
Yanick on 2008-08-12T16:44:55
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 someone chirp in something about Git every single step of the way you fleshed out svn4cpan, and that my comment might have had all the welcome quality of a forkstab at a convalescent eyeball. Sorry about that. <:-/ Although I currently have a preference for Git, I really think that svn4cpan is a wonderful idea, no matter what kind of vcs ends up being its backbone. 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 (as you obviously spent much more time musing over a Perl global repository than I have).
I'm convinced at this point that svn4cpan will not happen anytime soon because I don't have the time for it and nobody seems interested enough to back it (after 3 rewrites/tries for a TPF grant.) You could do it in pieces I guess, but I don't know how it will all get tied together.
Believe me, I feel your pain. But don't despair: all visionaries are eventually vindicated (okay, in most cases several hundred years after their passing, but hey, they *do* have the last word).
structuring chaos
Eric Wilhelm on 2008-08-12T20:27:58
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 author's own server, so now we have berlios, google code, and github too.) All of these tend to try to solve general-purpose collaboration issues and offer solutions which work within their own context, etc. None of that means much to a CPAN user wanting to figure out "$what broke $when" where $what may be one or more distributions and $when is a very simple linear sequence of said distributions having been released (despite claims that the ability to handle quantum releases is somehow necessary), and none of those systems will ever present a solution to those CPAN-centric issues.
But, I don't see this so much as a "social programming" problem, it's more about a historical record and discoverability (or at least, that's the chunk of our particular "social programing problem" which I chose to peel-off and attempt to solve.) Subversion provides a web service and a versioned filesystem, which IMO is exactly what is needed to create, publish, and maintain a CPAN history. With appropriate write access, said filesystem could also give every pause author a place to publish their work (including short branches of another author's work.) If they prefer CVS, perforce, bitkeeper, git, darcs, mercurial, blah, blah, or blah, they could simply use WebDAV to upload a YAML file indicating the location and type of their repository. That would take some standard/coordination to minimize pain on the client side, but would at least provide a standard place to start looking for forks/bugfixes/etc before you start hacking (and I would hope it could possibly become an accepted way to inform the author that you were interested in "trying something", as well as fun things involving smoke testing, documentations patches, etc.)
But these are just great and wonderful things which would be made possible by a simple versioned filesystem provided via a web service which paralleled CPAN. I think that is the important point and that limiting the implementation to something this simple is key to avoiding centralization bloat.
don't despair: all visionaries are eventually vindicated
Well, you can't eat "I told you so", but I have plenty of other unprofitable visions to pursue which are more important to me.
There's an example here... http://search.cpan.org/src/ADAMK/Module-Install-0.77/META.yml
EXTRA_META => q{
resources:
repository: svn://svn.versed.se/public/Perl/modules/JavaScript
},
Re:Doing it from ExtUtils::MakeMaker
grink on 2008-08-12T20:59:03
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.
Re:Doing it from ExtUtils::MakeMaker
Yanick on 2008-08-13T01:32:23
Ask, and thou shalt receive: http://userscripts.org/scripts/show/31660. Enjoy!
:-) Re:Doing it from ExtUtils::MakeMaker
grink on 2008-08-13T02:28:05
Wow, that's frickin' sweet!
I made
/repository:\s+(\S+)/ case insensitive by adding the /i at the end: /repository:\s+(\S+)/i Cheers
Re:Doing it from ExtUtils::MakeMaker
Yanick on 2008-08-13T02:36:23
Wow, that's frickin' sweet!
*g* Thanks.
[
//i ] Not a bad idea. I'll add it to the next iteration of the script!
Re:Doing it from ExtUtils::MakeMaker
grink on 2008-08-13T03:19:09
Yeah, I forgot to mention I changed it so it would work with Alias's example:
http://search.cpan.org/dist/ack/
Re:Doing it from ExtUtils::MakeMaker
Yanick on 2008-08-13T11:57:45
Andy breaking the specs? Tsk, tsk, tsk...
;-) This being said, the script has been updated and will match on any capitalization of rEpOSitory now. Thanks again for pointing this out!
Re: repository
Eric Wilhelm on 2008-08-13T08:35:59
From my reading, 'repository' is an official key in the standard, so shouldn't need to be case insensitive. Are there dists using 'Repository'?
Re: repository
grink on 2008-08-13T08:41:21
Yes, Alias's example has 'Repository' instead of 'repository'
http://search.cpan.org/dist/ack/
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).
Re: repository
Eric Wilhelm on 2008-08-13T15:30:24
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. Re: repository
grink on 2008-08-13T18:54:34
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 processRe: repository
Eric Wilhelm on 2008-08-13T21:04:25
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.)
