Re: license information and link to source code repository from your CPAN distribution
On 2013-01-08, at 1:31 PM, David Nicol wrote: > > > On Tue, Jan 8, 2013 at 12:14 PM, Olaf Alders wrote: > > uh, CPAN /is/ a public version control system. You have a favorite VCS and > > want to make diffs easily? Download, unpack, init, add, commit, work, diff. > > That doesn't sound easy at all. ;) For example, if you want to send a > simple doc patch to an author who has the source code on Github, you can > either jump through the hoops you're describing or > > a) fork the project on Github > b) edit the file in place on Github > c) click the pull request button > > That strikes *me* as much easier and you get built in request tracking. > > actually, for a small patch without an explicit VCS framework, the > antediluvian workflow of unpacking twice, editing once, and using diff -U to > make the patch is a little simpler. Of course you can't do that in a web > browser that I know of. At some point I switched to mercurial for such > one-offs, and as I'm still more comfortable with command line editing tools > than editing in place on Github, my workflow for editing something that's on > github still consists of checking it all out, editing it, then pushing it > back. I should look into editing in place with Github's web browser editor. I totally get that this isn't a one size fits all proposition and I wouldn't want to impose my own preferences on others. I should also mention that, on the other side of the coin, the workflow to merge a pull request (one click) can be faster than manually applying a patch. So, using something like this has the potential (in some cases) to make it easier for both parties. Olaf -- Olaf Alders o...@wundersolutions.com http://www.wundersolutions.com http://twitter.com/wundercounter 866 503 2204 (Toll free - North America) 416 944 8306 (direct)
Re: license information and link to source code repository from your CPAN distribution
On Tue, Jan 8, 2013 at 12:28 PM, John M. Gamble wrote: > > It was not intended as a constantly synchronized central repository of all > of CPAN. > That's what I meant, and it was something of a straw man.
Re: license information and link to source code repository from your CPAN distribution
On Tue, Jan 8, 2013 at 12:14 PM, Olaf Alders wrote: > > uh, CPAN /is/ a public version control system. You have a favorite VCS > and want to make diffs easily? Download, unpack, init, add, commit, work, > diff. > > That doesn't sound easy at all. ;) For example, if you want to send a > simple doc patch to an author who has the source code on Github, you can > either jump through the hoops you're describing or > > a) fork the project on Github > b) edit the file in place on Github > c) click the pull request button > > That strikes *me* as much easier and you get built in request tracking. actually, for a small patch without an explicit VCS framework, the antediluvian workflow of unpacking twice, editing once, and using diff -U to make the patch is a little simpler. Of course you can't do that in a web browser that I know of. At some point I switched to mercurial for such one-offs, and as I'm still more comfortable with command line editing tools than editing in place on Github, my workflow for editing something that's on github still consists of checking it all out, editing it, then pushing it back. I should look into editing in place with Github's web browser editor.
Re: license information and link to source code repository from your CPAN distribution
On Tue, January 8, 2013 12:14 pm, Olaf Alders wrote: > > On 2013-01-08, at 1:03 PM, David Nicol wrote: > >> ... > >> >> On the other hand, a comprehensive "CPAN by git" as an additional CPAN >> feature would have a measure of awesome to it, as an alternate >> distribution and synchronization method. I don't know what that means. What would this hypothetically entail? > > Well, there is GitPAN, but it needs a lot of love > https://github.com/gitpan Just to nip a possible misunderstanding in the bud, as far as I can tell the purpose of gitpan was to help CPAN authors who were not on github get on github, by starting their own accounts and forking their modules from gitpan (which I did, by the way. Thank you, Schwern). It was not intended as a constantly synchronized central repository of all of CPAN. So if you need a leg up on getting your modules over to a version control system, gitpan is a very useful starting point. -john
Re: license information and link to source code repository from your CPAN distribution
On 2013-01-08, at 1:03 PM, David Nicol wrote: > > > Recently I checked and only 50% of the CPAN distributions have a link > > to a public version control system: > > http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html > > uh, CPAN /is/ a public version control system. You have a favorite VCS and > want to make diffs easily? Download, unpack, init, add, commit, work, diff. That doesn't sound easy at all. ;) For example, if you want to send a simple doc patch to an author who has the source code on Github, you can either jump through the hoops you're describing or a) fork the project on Github b) edit the file in place on Github c) click the pull request button That strikes *me* as much easier and you get built in request tracking. Granted, not everyone uses Github, but it's a very minimal workflow. What Gabor is saying is that *if* your dist is actually available via Github/Bitbucket etc, you should let people know so that they can help you out. If you do include this in your Meta files, MetaCPAN will add a handy link right to your repo, which makes the process even easier. So, it helps people be even lazier about contributing, which is a good thing. If it doesn't scratch everyone's itches, that's OK too. At least, if you include your repo url, you're not making me search Github to see if your repo already exists there. > > On the other hand, a comprehensive "CPAN by git" as an additional CPAN > feature would have a measure of awesome to it, as an alternate distribution > and synchronization method. Well, there is GitPAN, but it needs a lot of love https://github.com/gitpan Olaf -- Olaf Alders o...@wundersolutions.com http://www.wundersolutions.com http://twitter.com/wundercounter 866 503 2204 (Toll free - North America) 416 944 8306 (direct)
Re: license information and link to source code repository from your CPAN distribution
> > Recently I checked and only 50% of the CPAN distributions have a link > > to a public version control system: > > > http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html > > uh, CPAN /is/ a public version control system. You have a favorite VCS and want to make diffs easily? Download, unpack, init, add, commit, work, diff. I do admit I've started experimenting with adding github repos for my modules, but I'm not at all certain that it is any improvement, and demanding that as a requirement seems unnecessary. On the other hand, a comprehensive "CPAN by git" as an additional CPAN feature would have a measure of awesome to it, as an alternate distribution and synchronization method. The converse interpretation of the data -- fully half of new CPAN uploads contain a link to a non-CPAN VCS -- seems like a valid cause for celebration, rather than alarmed finger-pointing at the non-adopters. dln
Re: license information and link to source code repository from your CPAN distribution
On Tue, January 8, 2013 10:43 am, David Cantrell wrote: > On Tue, Jan 08, 2013 at 10:06:31AM -0600, John M. Gamble wrote: > >> I think the finger should be pointed at h2xs, at least as it stands now. >> A >> programmer new to CPAN won't know about the META information, and h2xs >> just isn't oriented that way. > > I think the finger should be pointed at perlnewmod.pod, which > erroneously suggests using h2xs even for non-XS modules. It should just > tell people to use module-starter. > > And even if it doesn't work on Windows because of the getpwuid thing, > it's still better than using h2xs. > Well, I'm hoping this is a temporary problem. I've used module-starter successfully a couple of years ago. I'm submitting a bug report now. -john
Re: license information and link to source code repository from your CPAN distribution
On Tue, Jan 08, 2013 at 10:06:31AM -0600, John M. Gamble wrote: > I think the finger should be pointed at h2xs, at least as it stands now. A > programmer new to CPAN won't know about the META information, and h2xs > just isn't oriented that way. I think the finger should be pointed at perlnewmod.pod, which erroneously suggests using h2xs even for non-XS modules. It should just tell people to use module-starter. And even if it doesn't work on Windows because of the getpwuid thing, it's still better than using h2xs. -- David Cantrell | Bourgeois reactionary pig
Re: license information and link to source code repository from your CPAN distribution
On Tue, January 8, 2013 5:15 am, Gabor Szabo wrote: > Hi, > > those of you who read blogs.perl.org probably already saw my posts, > but I guess there are many others > on this list who are not reading that site. > > Recently I checked and only 50% of the CPAN distributions have a link > to a public version control system: > http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html > > 17% don't have the license information in their META file: > http://blogs.perl.org/users/gabor_szabo/2012/12/174-of-cpan-uploads-have-no-license-in-the-meta-files.html > > It would be nice if you could help improving the situation for your > modules. > I think the finger should be pointed at h2xs, at least as it stands now. A programmer new to CPAN won't know about the META information, and h2xs just isn't oriented that way. I can pass on the other META info (the module might be uploaded to CPAN before the author even decides on a version control repository, for example), but at a minimum h2xs should have been asking about license information. (I was going to compare and contrast with module-starter, which I have used and recommend normally, but I just encountered this unpleasant surprise: C:\Users\jgamble\prj>module-starter --module=Bogus::Example The getpwuid function is unimplemented at C:/Perl64/site/lib/Module/Starter/Simple.pm line 97. So I'm blocked there for a moment.) -john