6 posts tagged “cpan”

A few months ago, when discussing how to support the 'darkpan' (what Perl programmers call the vast body of perl code floating around the internet or in private companies that we know nothing about) I suggested leveraging the vast CPAN distribution system as a sort of continuous integration/build service which we could offer as a for pay service to companies using Perl.  This would have the dual benefit of encouraging corporations to package up their perl code properly (ie as  CPAN module with a Makefile.PL, etc) and could help raise money to sponser Perl development.

What I'm thinking about would be similar to a ruby only service I noticed: http://runcoderun.com

Check that out and let me know what you think.  What kind of services would the 'quasipan' be required to offer in order to entice companies into paying for it?  For example, what do you think of the idea of being able to build a EC2 or other cloud image type from a base OS that intergrate any given set of CPAN and Darkcpan modules?  Like, "I want a virtualbox VM with Perl 5.10.1 on debian with git, postgresql and Catalyst preinstalled, although with my private repo of proprietary code?"

I find as part of my normal course of writing perl moose based code, I do the following quite often:

Basically I tend to use the above with a core application class that is delegating work to several other classes.  In the above case, my general Library Class contains a Album class (presumable your library would hold an album and perhaps several other things).  In my Application logic I'm going to be calling methods on Album which have been properly normalized to the class which attempt to encapsulate the problem domain it attempts to solve.

I find the above form, although a bit verbose, to give me a lot of flexibility, particularly when I bring the application model into Catalyst via something like Catalyst::Model::Adaptor, which let's me define all the args in the global catalyst configuration.  Also, for testing, it's nice to be able to override the default classes, swapping in say a Mock Object or similar for the purposes of test cases.

In general use this construct commonly to avoid hardcoding all the connections between the elements of my applications.

Usage might be like:

Although I as mentioned, typically I instantiate this via Catalyst or as part of a more complicated application using an inversion of control container like Bread::Board. 

Recently with all the renewed effort on the part of Perl programmers to be better public advocates of our language, I've noticed an uptick in counter productive and quick frankly hateful comments directed at Perl.

I'd really like to find out why.  I'd also like to be reasonable and think there's actually something rational behind all this.  Several ideas come to mind.  For example, is all this negativity based on Perl's perception as spagetti code?  Is that just rumor or have many of you out there been required to step in and take over projects with difficult codebases?  Is it due to the fact that Perl 6 is still in development?  Has it to do with something many of you have experienced on the job?  Or maybe you've tried to get help from various Perl communities and gotten flamed?

I really have trouble understanding where this is coming from.  Personally, I use Perl because I find it works with my brain and not against it.  I've not found this to be the case with PHP, Python or Ruby.  I have nothing against any of those languages, but it makes little sense for me to force myself to relearn and rebuild my current skillset in a different language that doesn't really offer me a compelling reason to do so.  I'm deeply invested into the Perl community as a contributer to several important open source projects and that's what I enjoy about my job.

However the negativity is something I'd like to address if possible, because all this hate directed at Perl can affect me personally in terms of future employment and job options.  This directly affects my family, my wife, son and dog, so I take it very seriously. 

Because to be quite honest, the combined popularity of the most common scripting languages doesn't come close to countering the Java/C# juggernaut, and as someone committed to open source / free software this is an additional worry for me.  Neither of those languages are particularly committed to software freedom.  As far as I am concerned Sun (or Oracle now I guess) and Microsoft give some lip service to software freedom since that's a popular thing nowadays, but it's minimal and tactical in nature.  Free free to argue with me if you think I'm wrong, but I just don't see a deep and fundamental commitment.  Now, maybe you don't care about software freedom, but I'm old enough to remember the days when being a programmer nearly always involved proprietary tool chains and expensive certifications.  If it wasn't for the threat posed by developers and advocates of free software there would be no Java Community Process, no Mono, nor would there likely be quality free version of IDEs like NetBeans, Eclipse or the various free 'Express' versions from Microsoft.  There would be no free, online versions of documentation.  So it really seems to be we should be working together, not against each other. 

Several possible points of collaboration that suggest themselves would be standards for testing, deployment and management of applications.  Also, we often depend on a core set of external libraries, such as MemcacheD, xml and xslt parsing libraries and so forth.  It would be great if we worked together to improve these and to ensure that the language bindings were of consistent and high quality.

Each of our communities has different strengths and weaknesses.  The Rails group are great at advocacy and Ruby has a reputation for delivering nice, clean code.  Python really focuses well on education and ramping up newcomers.  Perl has great testing and deployment tools, as well as CPAN.  Why are sniping each other when working together would have so many benefits?

With all the discussion about CPAN reliability and hair pulling over worrying what's going on in the Darkpan, I was just thinking: Why not extend CPAN for Corporate / Non Free stuff?  Basically we'd extend CPAN so that authors could release source code under more restricted licenses but  you'd have to pay a reasonable fee for the privilege.

This would accomplish the following:

1) Encourage people to follow the best practice of writing everything as CPAN module, so that they could take advantage of CPANs vast smoke testing system and receive more timely alerts to when new releases of dependencies causes breakage.

2) Be a source of income for the Perl community, which we could use to fund important stuff

3) Create less worry about causing breakages

4) Allow a company to generate an alternative income source for their code.

Now, I'm an open source believer, and do my best to convince my employers to release as much code as possible, since this almost always ends up as better code once it's in the wild.  But there's always going to be some things that are in house, stuff that reflect the unique business rules and the companies investment in technology.  Given that we all agree validating Darkpan is important and that writing your code as well tested CPAN modules is the right way to code Perl, do we think there's an opportunity here to build out something everyone can benefit from?

This mediation was removed from part two of the BlueChild project.  Part two deals primarily with ways to setup your development instance, which obviously will revolve to a large degree around CPAN.  Originally meant as a discussion about how CPAN shares merit and responsibility, I decided to remove it since it felt a bit too tangential, as well as lengthened what was already a long blog posting.

I've come to strongly feel that a key difference between Perl and other languages is the depth to which you need to engage the Perl programming community in order to progress in skill and make best use of the available resources.  I am not saying other languages don't also have large communities or engage in community building.  However, Perl as a language seems to be to be more shaped by the community and the push and pull of ideas batted about the mailing lists and on IRC chat rooms than most other programming languages.  Partially this is due to the fact Perl does not have one single company behind it with particular vested interests in promoting and shaping it.  This is combined with the distributed and anarchistic nature of CPAN development to promote a culture that is extremely merit based (you get help and respect first by the nature of your contributions to the community) and yet insists on sharing responsibility for many key projects as widely as possible.  This is achieved first by the ease at which it is to contribute code via shared software version control systems and by how widely co-maintenance of those modules as published to CPAN are.

On CPAN, it's normal for “handoffs” to take place over the maintenance of important modules.  This distributed style encourages the development of sustainable and useful bits of code that can be glued together to form more complex systems.  This is one of the key differences with Perl.  Many other languages have distributed systems similar to CPAN, but they tend to be based as plugins around existing large projects.  Perl tends to follow the Unix approach, where each module is intended to do one and only one thing as well as possible.  Although this requires more upfront effort on the part of developers to learn the tools, it results in greater flexibility.

Since you have a big investment in so many of these shared resources, it encourages people to reach out to the primary authors of important projects.  You might have a bug report, and hopefully a test and maybe offer a patch to fix the issue.  I see a lot of this type of shared responsibility.  For example, one developer might take the lead in releasing a new CPAN module during the first few releases (thus shaping the overall contours of the module) and then grant co maintenance to one or more important users of that module.  Or, you might assign the job of release manager to someone you, as the lead, is trying to help mentor.  In any case, this kind of responsibility sharing, via CPAN and increasingly via source code control systems such as git and github is a means by which the community shares merit and grows talent.

Being so, you really need to track what's going on in the community, and participating to the degree you are able.  I recommend you do at least the following:

Following trends and updates to CPAN.  I subscribe to a syndication feed and check it daily at the minimum.  After a while you will get to learn which projects are being aggressively worked on.  Hopefully you will see a few useful things you didn't know about.  For example, I discovered Moose because it's a project with a lot of development and it kept showing up in my feed.

For the projects important to you, join the mailing lists or IRC chats where developers and user hang out.  I recommend 'lurking' a bit to get to know who is who and to get a feel for the tone of the group.  If you haven't been on IRC before, there's a great and easy to use Firefox extension called “Chatzilla” which although not the most feature-full IRC client, will help you get going.

For help getting to know Perl IRC channels.

There's a couple of blog aggregators you should know about:

planet Perl
planet Catalyst
planet Iron Man

I probably missed a bunch, feel free to add in the comments.

One thing I'd like to add.  CPAN get's a lot of flack at times when it's difficult to build your software due to changes somewhere in the dependency stack.  This used to frustrate me as well, but now I have come to understand that with a system as large and complex as this, keeping it working is work and not always easy work.  CPAN can be great when everyone takes responsibility for the bits they need.  I think the biggest issue is getting out all the information and tools needed to make it much easier for people to join and and solve problems on CPAN.  We need to make it easier to work with the source code (via something like git's easy cloning feature) and easy to find original authors and get co maintainance roles.  We also need to do a better job of teaching people how to become CPAN authors and get contributing.  I think if we can do that, CPAN will become as reliable as it is deep in features.

Here's an article you might have missed.  Nice summary of the main features of the 5.8 version of Catalyst.