I am extremely grateful to each and every contributor, and I am deeply moved by the overwhelming support of the Perl community at large. As a humble token of my appreciation, every contributor will get a free lifetime account on Stratopan. I will also list the name of every contributor in the documentation for Pinto and on the project web site.
I especially want to thank Viacheslav Tykhanovskyi, Gabor Szabo, Andy Lester, and Sawyer X who worked tirelessly to help spread the word about the campaign. I also thank brian d foy for organizing the campaign, and Crowdtilt for generously allowing us to use their platform free of charge.
I believe the success of this campaign has a lot to teach us about the strength of the Perl community, the power of crowd funding, and the future of open source software. So over the next several days, I'll be blogging about each of those things. And of course, you'll also be hearing about the progress I've made toward implementing the promised features in PInto.
Again, thank you, very much!
Sincerely,
-Jeff
]]>So there will be two one-hour jam sessions in the #pinto channel on irc.perl.org this Thursday, May 2. The first will at 14:00 and the second will be at 18:00 (all times GMT). If you haven't used IRC before, this is an excellent guide.
Hope to see you all then!
Stratopan will host both public and private repositories with any combination of proprietary and open source Perl modules. And Stratopan is built on Pinto, the open source tool for creating custom CPAN-like repositories, so it has the same helpful tools for managing your application dependencies.
]]>With some help from the wonderful crew on the #metacpan channel, I was able to put together a query that would tell me which distributions contained any particular version of a module. And by taking a bit of code from cpanm, I could even use notation like ">=1.34, !=1.56, < 2.45".
I'm still a novice with the MetaCPAN API, so the query felt cumbersome to me. Plus, it required two trips to the server to get the final answer. Since I have a Pinto repository that also contains all of BackPAN, I tried to roll my own minimal CPAN API.
Each of these queries will return a JSON array containing the AUTHOR/Dist-File for every distribution that contains the requested version(s) of the Plack module. They are sorted most recent first. Feel free to try these at home with your favorite module (beware the database is about 2 weeks old now)...
Where is Plack?
http://lookup.stratopan.com/Plack
Where is version 1.0016 of Plack?
http://lookup.stratopan.com/Plack==1.0016
Where is a version of Plack that is greater than 0.9949 and less that 1.0006 but not 1.002?
http://lookup.stratopan.com/Plack>=0.9949,<=1.0006,!=1.0002
But I've already run into one stumbling block: unauthorized distributions. Pinto doesn't know about PAUSE's permission system, so it will report distributions that don't contain "official" versions of the module. But MetaCPAN does know about the permissions, so you can filter unauthorized modules out of the results.
So in the end, building on the MetaCPAN API is probably the right way to go here. But it was an interesting exercise to see what I could do with a very large Pinto repository. And it only took about 20 lines of code!
]]>That seems like a golden opportunity to me. Those companies are making some serious money (New Relic is likely to do an IPO this year). I think an enterprising Perl developer could get a piece of that pie.
If you put together the right hooks to support one of their monitoring agents from Perl, I am certain those companies would be happy to license you work from you. Or at least offer you a good job.
Individually, those companies may not feel the Perl market is worth the effort, or perhaps they just can't find the expertise to support Perl (good Perl devs are not easy to find). But if you find a way to leverage code across all those companies, then I think you would be sitting pretty.
]]>Other than that, it's not anything special. It's a mid-sized Linode server located in Texas with 8000 gigabytes/month of traffic. I get a warm and fuzzy feeling from hosting a CPAN mirror. It makes me feel like a more useful part of the community.
Feel free to point cpanm or pinto at http://cpan.stratopan.com. We'll see if my hosting bill goes through the roof :)
]]>Last week a new version of CPAN::Meta was shipped to CPAN. Unfortunately, it caused a test to fail in Module::Build. In turn, that set off a whole chain of downstream failures in hundreds of distributions that depend on Module::Build.
So if you were building up a complete application stack last week (like on Stackato or Heroku) and you were pulling the latest dependencies from CPAN, you were hosed. This sort of thing happens all the time, and when it bites you, it will be at the worst possible time.
Pinto also uses Module::Build. But those who were building it with the installer at http://getpinto.stratopan.com were completely insulated from the failure. This is because the installer pulls dependencies from a private repository. Unlike the public CPAN, that repository is stable and only changes when I decide to upgrade or add a dependency.
Fortunately, the problem with CPAN::Meta was short-lived. Dave Golden had released a fixed version only 23 hours later. But I think this perfectly demonstrates why you should lock down your dependencies with a tool like Carton or Pinto.
]]>Usually the offenses are pretty minor -- misspelled or missing keys in the META files, or a non-parsable version number. Some of us have probably made local patches of these distributions to fix those problems. But there's no reason everyone should have to do it.
So I had an idea -- what if there was a secondary public CPAN where folks could contribute patched versions of these older distributions? Read the rest of the story here:
]]>I'd love to see pretty logos or icons for each module on MetaCPAN. Perhaps we could add a new attribute to the META spec that points to an image file inside the distribution, or a URL somewhere.
]]>So naturally, I was pretty pleased when I heard that CGI and some other modules were going to be removed from the core in perl 5.20. But lately, I've started to change my view on that. Here is why...
]]> I've been watching the p5 porters for a couple years, and I feel that major enhancements to the language just aren't going to happen. There are lots of different reasons for that -- some technical, some social. I'm not bitter and I'm not pointing the finger. This is just what happens when programming languages and their communities mature. The same will happen to Ruby and Python.But I know that Perl still has a very long and prosperous life ahead of it. But if the future does not lie in the language itself, then where does it lie? I think the answer might be the modules it ships with.
Perl owes some of its success to the fact that CGI.pm was right there in the core at a time when lots of people were starting to do dynamic web sites. Here we are 20 years later, and CGI-style progamming has been replaced by frameworks with routers and templates and controllers. It makes sense to remove CGI.pm from core now, but perhaps we should also be looking to put something in its place. And we have plenty of things to choose from: Catalyst, Dancer, Mason, Mojolicious. How we pick one is a whole other story. But I contend that shipping one of them in the Perl core could be path to the future [1].
I understand that a fatter core presents a maintenance burden for p5p. But these frameworks actually have pretty large and vibrant communities. Most are probably bigger that p5p itself. So putting one of them into core could help bring many new contributors into the p5p sphere. Some of them might even make significant contributions to the language while they are there.
To put it another way, some folks call Ruby a language with "batteries included". At one time, Perl was the "batteries included" language too, because it had regexes, and interfaces to common system calls, and *gasp* CGI.pm. But now, the world has caught up and we expect more from our languages.
So maybe we need to think about what kind of stuff people want to do with computers these days, and then focus on providing them with a Perl offers them a way to do it. Perl doesn't have to be all things to all people, but it ought to make a strong effort to appeal to some group of people. That probably means putting more modules in the core, rather than less.
[1] The same thinking could potentially be applied toward DBIx::Class or Poe, or some of the other widely used frameworks.
]]>http://twit.tv/show/floss-weekly/246
Big thanks to Randal Schwartz and Aaron Newcomb for having me on the show!
]]>Pinto is a robust tool for creating custom CPAN-like repositories of Perl modules. You can fill your repository with any combination of private and public modules, and then build/test/install them using the standard tools (e.g. cpan, cpanm, cpanp). Since you control the repository, you'll get exactly the same modules every time. Pinto also has some novel tools for tracking and managing changes, so you can upgrade modules with confidence and control.
So I started thinking...what if Perl5 was developed on GitHub[1]?
Moving a large and mature project like Perl5 to a new set of tools and workflows will certainly not be easy and I expect a lot of resistance. I don't expect perfect feature parity either -- some capabilities will be gained and others will be lost. But GitHub has worked really, really well for a lot of projects (including Perl6). So I think it is definitely worth investigating.
In my heart, I hope that GitHub eventually becomes the primary platform for Perl5 development. But I don't want to alienate everyone who is comfortable with the current development tools & processes either. So I'm going to try and get the best of both worlds by creating a two-way bridge with GitHub. For example, submitting a ticket to RT could automatically create an issue on GitHub (and vice-versa). Or making a pull request on GitHub could automatically generate a patch and send it to the p5 mailing list for review.
Of course, this is all speculative. But I've already taken the first steps: I have established a Perl organization in GitHub with a (mostly empty) Perl5 repository. Next, I'll look into marshalling commits back and forth between GitHub and perl5.git.perl.org. And I'm especially eager to try migrating all the tickets from RT into GitHub's issue tracker.
I don't know how this will all work out, but I am optimistic. I'm even hopeful that it might bring new energy and new blood into Perl. So give a shout if you like the idea. And please contact me if you'd like to pitch in.
[1] Yes there is a mirror of the Perl5 repository on GitHub, but it is read-only. I'm talking about doing real development of the P5 core directly on the GitHub platform.
]]>I started cooking a big editorial essay in my head, but I'm just going to try and boil it down…
So long as a fixed number ("5" in this case) is *prominently* attached to Perl, it will be seen as stuck. Specifically, it is stuck behind that thing called "Perl6".
You may understand the distinction between "Perl" and "Perl5" and "perl-5.16.2", but the rest of the world (including many developers) does not.
Others (notably Apple, Java, Mozilla) understand how to manage perceptions through names and numbers. We should learn from them.
Continuing the affiliation between Perl5 and Perl6 is harmful to both camps. Negative or false perceptions about either needlessly end up affecting both.
The Perl5 community must pursue its own best interests and cannot be held hostage by the name and number of another language.
Establishing a way forward through both minor and major (i.e. non-backcompat) releases to Perl5 will help to energize and accelerate development.
The Perl6 community will not take offense at anything the Perl5 community does. We all understand that we have common roots, but we are now on separate paths.
I will not argue whether Perl is thriving or dying, but I will assert that the language and community does not receive as much "buzz" as it deserves.
Rebranding, renaming, and/or renumbering are useful tools for generating "buzz." But these alone are not sufficient -- a compelling message is also required.
Initial reactions to these kinds of changes are always mixed. But those feelings will fade and the benefits will come over time.
Yes, this is mostly about marketing and image, but that doesn't mean it isn't worthwhile. Perceptions do matter, regardless of whether they are rational.
Not everyone in the community cares about marketing (nor should they), but we must not impede or discourage those who do. We are all on the same team.
If we want things to *be* different, than we must *do* things differently. Let us not be afraid to try.
]]>Be aware that this site is not secure nor reliable, but I think it demonstrates the concept pretty well. Most of the links on the landing page go nowhere. Just click the big "Sign Up Now" button and you'll be on your way. If you like what you see, let me know.
]]>