pshangov.myopenid.com

• Website: pshangov.myopenid.com/

Recent Actions

• Commented on Your Personal CPAN In The Sky
  There are certain downsides to using a version control system to manage your dependency versions. The most important one from my experience is that it makes it difficult to have concurrent versions. At $work we have multiple versions of our...
• Commented on Perl numbrenclature support
  The more I think about Raptor Perl the more awesome it sounds to me :-)...
• Commented on Roles without Moose?
  Have not used it, but can Mouse::XS be a useful choice here?...

Comment Threads

• rcaputo.myopenid.com commented on Roles without Moose?

  Hey, Schwern! Where are you keeping your benchmark code? All benchmark results should cite code.

• Jeffrey Ryan Thalhammer commented on Your Personal CPAN In The Sky

  Ah, that is precisely what makes Pinto unique. It can have multiple indexes, so you can keep different stacks of dependencies at the same time. The version control mechanism is customized for Pinto, so you're basically versioning the individual indexes, not the whole repository itself.

  You could use Pinto to stash your private modules and CPAN/BackPAN dependencies. And within the same repository, you could have "development" and "production" versions of the index. Then you can use cpanm + local::lib to fetch all the modules (from either index) and build/test/install them into a d…

• Kang-min Liu commented on Your Personal CPAN In The Sky

  I also like the idea in several aspects. But freedom and authority would be the two major factor that makes me happy.

  Current CPAN basically suggests people name their distribution according to some fuzzy classification rules. Top level namespaces tend to be preserved for some sort of special purposes. IMHO this kind of framework is becoming more like some sort of barrier then support. I can probably still name my testing-related work like FrogbozTester, but with some worries that somebody will just jump out and submit a bad review saying "Why using another top-level namespace instea…

• chimerix commented on Your Personal CPAN In The Sky

  gugod, CPAN is about sharing, and if you just toss random-named stuff into the pot, you wind up with a cesspool like Python's PyPi or Ruby's Gems. Their authors are frequently vain hipsters who appear to be in a contest to make the weirdest names.

  Whenever somebody makes a comparison of Perl to another language, the first pro in Perl's favor is CPAN. If we lose the community professionalism for the resource it no longer becomes a selling point. I always avoid odd-named modules unless they have reached critical mass (like Moose or Dancer) because it usually reveals the author was thin…

• Jeffrey Ryan Thalhammer commented on Your Personal CPAN In The Sky

  I think that is Kang-min's point: to use the Perl toolchain *without* having to coordinate namespaces. A custom CPAN-like repository would let you do just that. If you eventually do decide to release to the public CPAN, *then* you can worry about namespaces. But until then, you can just point cpanm at your repository in the cloud to get your stuff, no matter what it is called.

  Some developers still feel that CPAN-style distributions are only useful for code that will be released to the public CPAN. I want to help dispel that belief.