On CPAN Namespaces
After the public buyers-remorse that I (almost) had on the name of my latest module Tie::Select, I got to thinking about the filling of CPAN namespaces.
CPAN is awesome; many have said that it is Perl’s killer app. It has tons of modules to do many many things. The problem is that some of the obvious names are gone. Certain namespaces have implications. For Tie::Select I thought of IO::Select, which exists. I thought of going underneath an existing module’s namespace, for example IO::Handle::Select, but this implies, at least to me, that it is either a part of, or derivative of IO::Handle. Its not, and in fact it isn’t even OO as that module is.
I have settled on the current name for now, but I am not totally happy with it. I got to thinking about other naming problems I’ve had. (And note I am not complaining about any of this, just ruminating):
Duke Leto’s SWIGing of the GSL library effectively took up the entire
Math::GSLnamespace. MyMath::GSLx::ODEIV2needed that little x to “clear things up”One might expect that my
MooseX::Types::NumUnitusesMooseX::Types, but it doesn’t. Perhaps it should, or perhaps it should be in another namespace. Then again, this is the descriptive one.It seems like there are more that I am forgetting
Anyway, it begs the question, as CPAN continues to mature, what happens as the namespaces fill up? What happens to old dead modules Tie::CSV_File which aren’t really worth fixing, but will decrease the searching signal-to-noise?
Gasp! What happens when ACME:: fills up!
I know that some people’s answer will be to adopt the old modules. But what if I don’t plan to keep the API or the implementation. What if the functionality is different but the names should be similar (my Tie::Select vs IO::Select).
I know I’m rambling a bit now and I can’t say that I know what I want, but I know what I don’t want. I don’t want new CPAN modules to have to start picking odd names just to have their own namespaces. I’m sure many of us have see Miyagawa’s module’s funny names and their reasoning.
But there just aren’t enough descriptive names.
As I delve into the deeper Perl magic I like to share what I can.
I would rather use Local::Select
As brian d foy comments on the other post,
Local::is reserved for your own use.Anyway this post isn’t really about that anymore, its wondering if in several years there will be any descriptive names left?
Wait until the
MooseY::branch starts …I’m pulling for
MooseXX::andMooseXXX::…I wanted to raise this very question myself, but from a different perspective. I’m seeing people take more and more pointless spaces for pointless modules, and quite frankly, it irks me.
Is this aimed at me? If so I counter with two points. First, every blog post I make announcing my (admittedly sometimes smaller) modules gives the real-world reason that I needed this module. Second, I try to put my module under the namespace where it belong, keeping the more valuable toplevel space clean. You’ll notice that I didn’t name my Tie::Select instead Handle::Select because Handle:: hasn’t been used yet and I feel it is not my place to start.
One thing that would help a lot of people is simply reading On the Naming of Modules (pause.perl.org), which I tend to post whenever someone announces about their misnamed
Net::module or new::APImodule. The Unicode section needs clarification though since it first states Unicode and unicore and then Unicore/unicore. A lot of people—myself included—haveUnicode::modules. If that namespace is in fact off-limits, then we have a lot of non-compliance and a lack of an appropriate namespace for Unicode-related modules. I’m hoping the first reference is supposed to be Unicore.Wow wow wow! Hell no, I wasn’t talking about you. :)
I also think it’s awesome you write posts about your modules and that prompted me to write about MooseX::Role::Loggable recently.
Sorry I gave the impression I meant you.
Good, I’m glad. I had a couple days there when I couldn’t do anything right (most of them having nothing to do with Perl). I guess I was feeling a little defensive.
Actually now you have made my day!
It’s all good. :)
So my new Net::Text::API module should be called something else??
May I recommend, Local::Net::Text::API::Tiny
If we could please just have everyone on CPAN comment here so I could say “no” until we hit the right one(s)… :)
BTW MooseX::Types::NumUnit is now fully using the MooseX::Types framework. After discussions with the Moose Devs, the namespace clash is “intentional” in that types should all come through this framework.