Hi Lennart, thanks for the reply.
Lennart Regebro <regebro <at> gmail.com> writes: > On Tue, Dec 22, 2009 at 10:14, Steffen Mueller <smueller <at> cpan.org> wrote: > > Let me add two nits here: > > It's Perl, not PERL. The name of the language is *not* an acronym. Some > > people > > are really picky about that. > > In a language where you can spell any functionality in millions of > ways, you are not allowed to spell the language however you want!? > Ok, Pörl. I mean Perl. IMO, the "There is more than one way to do it" mantra gets old very quick. It's generally appreciated as something along the lines of "There is more than one way to do it, but most of them are bad." You'd be surprised how many tools are converging into best practices in Perl. Cf. modules like Moose or DBIx::Class, etc. There's still at least one new, sucky configuration parser uploaded to CPAN every day, though :( Anyway. I appreciate the humour ;) > OK, so that would be docstrings and stuff then. It's true, if we had > something like that it would work as an incentive for making more such > documentation. I agree. That helps tremendously. > > You could get the same page via > > http://search.cpan.org/perldoc?PAR::Repository::Client. This is an example > > of > > how CPAN works on namespace and distribution level. After a new file is > > uploaded, its contained namespaces (packages/class names) are added to the > > index if they're not already there. > > How does it handle if two modules implement the same namespace? There are two ways to get a namespace (non-recursively!). Either you file a form with the PAUSE admins or you're simply the first to upload under the name. If someone does something outrageously stupid wrt. namespaces, he feels the wraith of the community. If that's not enough, the admins can act. But this is very, very, extremely rare. > > The index always contains a reference to > > the distribution that contains the newest *authorized* version of any > > namespace. > > Who authorizes it? The "first come first serve" principle. Or if there is a disagreement/ clash between authors, the PAUSE admins. > I have to say that I vastly prefer not to have any authorization and > allow anyone to release anything in any namespace. But then I am > getting fanatically anarchical in these issues. You can not organize > freedom. But you have to. What you're saying here means you virtually throw away the ability to do anything useful with namespace meta data. Think about it like this: If you install any module from CPAN (and only the valid ones end up in the index), you can use all of them in the same application. If module A and B could both implement Config::Parser, then you couldn't use both of them at the same time. Now, this may be a case where my lack of Python makes me look silly. In Perl, when I refer to namespaces, I'm actually thinking of hierarchical class structures, not C++ style namespaces which may in turn contain arbitrary classes. Effectively, though, the C++ namespaces + classes end up about the same as Perl's namespaces. Still. We allow for a lot of creative freedom. We just don't want a random newbie upload a shiny package "DB" which implements his idea of a database interface when it's really the name of the package that implements the Perl debugger. He can still upload. The file will be accessible in his CPAN directory. Users can install it from the CPAN shell as "install NEWBIEUSERID/DB-1.00.tar.gz", but not as "install DB" or "$ cpan DB". This is a safeguard against insanity and it's the thing that means that you can trust "cpan PAR" to always install the Perl Archive Toolkit that was released by Autrijus Tang, Roderich Schupp, or myself (we share co-maintenance). It's never going to be some random junk. And that you auto-register a namespace on upload is the guarantee. Best regards, Steffen PS: Let me comment on another post of yours quickly. No. In the Perl community, the name "CPAN" doesn't yield confusion. It's just a way to refer to the whole ecosystem including but not limited to: * the FTP/HTTP archive * PAUSE, the Perl Authors Upload Server and the indexes it generates * The various web frontends * The "toolchain", i.e. the set of tools that can create new distributions as well as build and install them. * The huge set of tests and modules that do the testing. * The CPAN.pm or CPANPLUS modules that provide the user interface (shell, etc) and do the dependency resolution, downloading, local unpacking, controlling of the build steps. * The "cpan" and "cpanp" CLIs to CPAN.pm and CPANPLUS respectively. Let me also refer to Ash Berlin's recent posts on a similar subject. PPS: All, could you please not turn this thread into a flame war? Civility and mutual respect go a long way towards getting shit the fuck done. Pun intended. :P _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
