[Distutils] Python people want CPAN and how the latter came about
smueller at cpan.org
smueller at cpan.org
Wed Dec 23 10:32:47 CET 2009
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
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
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.
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
More information about the Distutils-SIG