Here are the minutes from the CPAN BOF at YAPC::America::North,
Sat. June 16 2001 at the Delta Hotel.
In attendance were roughly 40 people in attendance, gathered to discuss
some outstanding issues with CPAN, and ways to fix them.
The agenda as discussed was as follows:
Group Authorship
Build (+ build requirements)
Test.pm and it's alternatives
perlmodstyle (+h2xs)
CPANTS
[Damian's interlude]
CPAN Bug Reporting
Group CVS
Versioning
Module ratings
Perl6 Library
PPM
NAPC [Ingy's idea of rethinking CPAN and the Perl Core modules]
interfaces
code review
scripts
modules@perl.org
Z.
-------------------------
Group Authorship
Group IDs are available
SPUG is a group ID
Reefknot was prevented
shouln't have to lie with pause
ingy didn't run into the problem
bad precedence?
spug is a group defined by people, reefknot is defined by a project
reefknot wasn't presented as vaporware
inline is now group authored; other should follow this example
last uberrelease was done in 8 trials from a website; CPAN is a code
repository; alpha things out doesn't scale on CPAN; versioning is
another issue; core group works on development, informally, but
publishes URLs publically
reefknot is developed on sourceforge, release on CPAN; 3 possible IDs
but no one knew which ID would publish reefknot
one person with one ID insures consistency
pumpking should be identified by the CPAN ID
still up in the air
Resolution: open issue
Build (+ build requirements)
Remake MakeMaker without make; current code is fossilized, and no one
understands it anymore (except Sarathy)
MakeMaker must go;
Basic flaw: uses make; overpowered for most modules on CPAN; instead
of running Makefile.PL; determine 90% of the functionality people use
and put it into a config file; MakeMakerNG reads the manifest,
configuration and does all of the basic stuff; process for the module
author is a lot simpler as a result (Include simple XS code)
anything more complicated (TK) would still need to call make/cons/etc.
focus on how module writer writes the code, not how to download
binaries thorugh PPM
should simplify the way modules are installed should be simplified for
80% of all users installing modules
Brian: MakeMaker isn't evil, if you never look at it; use stable
processes in place, make a dead simple interface for building modules
oneliners should package a tarball and go
Wrap something over MakeMaker and rewrite the underlying implementation
can go later.
If we redo makemaker, a whole host of security issues disappear;
Makefile.PL is no longer untrusted; configuration file is more secure
Action Item: create a series of interfaces, and see which ones works
Action Item: Talk to Andreas
Test.pm and it's alternatives
Test.pm used to be the only thing to write tests (and Test::Unit)
Test.pm isn't very well documented at all
Schwern started working on alternative modules: Test::More - everything
you ever wanted to do with testing
Edge cases from perl-qa list: no one writes tests at all. Solution:
Test::Simple, with a single method
Test::Harness is being refactored (Ingy: needs to work with -T)
Test::Simple/Test::More are out there, but no one knows about them yet
Action Item: Test Tutorial manpage (perltesttut)
Test::Harness has been fossilized for a very long time; a few new
features added but nothing big;
Open issue: remote installation and checking whether remote tests are
OK; requires print interface to go away (or not be the only interface)
Create simple tests for each bug report
Resolution: discuss further on perl-qa@perl.org
perlmodstyle (+h2xs)
Before we start rewriting modules for Perl6, start codifying good
module style; we're better at writing modules now than when Perl5 was
released
Skud working on perlmodstyle in POD and possibly a PDD for Perl6
Summary:
Before you start writing a module
designing and writing a module
documenting your module
release considerations
Tests should be pulled out of release considerations
Version control should be pulled out
release considerations should be renamed
Issue: difficult to identify which releases support which features
Not everyone is running all back releases to test compatibility
Action Item: automation script for testing modules against back
releases
Before you start writing a module:
has it been done before
if it's been done in perl, don't reinvent the wheel (?)
if a module does almost what you want, start with a patch,
take over maintainership, etc.
do one thing, do it well
modules should be modular
- clearly defined scope, one sentence
What's in a name
- descriptive
- consistent with existing module names
Emphasis on suggestions, not "thou shalt not"
This is only a style guide, not a tutorial on everything you want to do
Issue: package naming (esp. without make dist)
docs are hard to find
Perl Debugged is the first book that goes through MakeMaker very well
perldoc (5.6.1) perlnewmod: tutorial on writing a modules; focuses on
how; perlmodstyle focuses on what to do after you've started writing a
module
Designing and writing a module:
whether or not to use OO
defining your API
naming conventions
parameter passing
design for flexibility
specify your version requirements
Document your module well
Document for the user
release considerations
Version numbering
Prereq modules, dependencies
Packaging (standard packaging)
Testing
backwards compatibility (maintain it)
Licensing
Error handling
Action Item: help writing whether or not to use OO:
rrwoo@cpan.org, schwern@pobox.com
Action Item: more contributions on 'defining your API'
Action Item: add common pitfalls
Action item: whether we can use this as an evaluation tool with CPAN
modules; [bleed into cpants?]
h2xs: if there is a good style for writing perl modules; start with
newpm (starts with suggested style)
Action item: Don't focus exclusively on starting, focus equally on
creating a module with existing code as well (Ingy)
Idea: Autogenerate POD stubs, POD Test stubs, similar to javadoc
(New Perl Module Wizard)
Testing, Module Authoring Tools, Distribution
CPANTS
Test for good style (based on perlmodstyle)
Modules vs. Packages: packages are the foundation of automation and
testing
2500 named packages (current version), 1900 in october, 1400 authors;
most haven't submitted anything, of those who submit, most submit only
one module; a few dozen submit multiple modules
making the barriers to entry high is one way to ensure good code on
CPAN, but it's a crappy way to go about it
Natural selection through ratings?
Should stop saying "put it on CPAN?" No.
What's a good module? We can write it down, but can't automate it;
human intervention required; use Kwalitee (like Quality, but much
easier to measure). Look for the dirty ashtrays, test what's easy to
test
Look for qualities that good modules tend to have:
README
MANIFEST
Makefile.PL
Tests, pass tests
*.pm files compile
works with all perls in current use
works with all common perl configurations
test coverage
complexity rating (B::Fathom)
ratio of code::docs
Not required to "pass" all tests; need to figure out what lets 80% of
modules through the barrier
Key principle: don't trust the module author
PPM/Automated Build process: test tests that author wrote; 1 failure
out of 3 or 1 failure out of 6000?
CPANTS stores metadata about module testing; sometimes OK when modules
fail with good cause
CPANTS always maintains a human face
CPANTS heuristics should be constantly adjusted; bootstrap with known
sets of modules that are reeelly good and reeelly bad; CPANTS should
agree with these heuristics
CPANTS isn't just a rating system; it could be a tool for module
authors
Issue: Module abandonment: nag list (similar to a centralized bug
repository); also a way to determine how well a module is maintained
Issue: Kudos list; more reviews; ratings
CPANTS's principle is to build and agglomerate existing technologies
and produce new modular technologies
CPANTS also exists to test new versions of Perl
Action Item: distributing the workload
Action Item: B::Simple - require a backend for processing Perl code
Action Item: Break up CPAN.pm and PPM.pm
Absence of CPANTS approval doesn't mean a module is bad; presence of
CPANTS approval doesn't mean that a module is good, it has a good
chance of being good
Sourceforge: cpants-devel, cpants-announce
Damian interlude:
at the end of the bell curve
Simplifying module creation is a good thing
Too overwhelmed, probably won't manage a nag list, bug reporting db,
etc. and will probably get a bad rating with CPANTS
People will ignore the red bells around CPANTS ratings stating that
this module is well written, but not necessarily good
Automated distribution tools do sound like a good idea (won't
necessarily use them myself)
Like the idea of a replacement for h2xs (probably won't use them)
CPANTS is essential; need as much feedback as I can get; cpan-testers
is incredibly useful to me; can't test on the mac anymore; testing
needs to be expanded
ought to have a way to test whether a module runs on every platform,
with a list of modules it doesn't work on
some proposed features would be better if they were opt-in/opt-out
(Kudos list, nag lists, bug databases, etc.)
People do this work out of the goodness of their own heart on their own
time or stealing time from their boss; produce tools that help people
to spend their time better, but don't rag on them for not being as
active as possible
CPANTS might be better as opt-in
Schwern: 20% of CPAN is used regularly; get constant feedback; written
by the few authors writing more than one+ modules; those authors are
already getting good feedback; need to get good feedback to authors
with one/two modules on CPAN.
CPAN Bug Reporting
set up gnats/bugzilla/etc. for all of CPAN, one per module/author
perl -MInline reportbug; tar it up and email to author; ought to be
more core to the language
Produce automated reporting tools; more reason to make it standard
Action item: ReportBug module by Damian and Ingy
Mail volume is an issue
Issue: mark modules as abandoned by author
Action Item: reportbug should feed the bug reporting database
Opt-in by virtue of author's inclusion of ReportBug support
DocBugs identified by dozens of different errors with different
explanations on different platforms with the same module version;
can be identified by standard preamble
Action Item: determine a premable to quickly identify common errors
Group CVS
Action item: Ask Ask to open up CVS on onion for public r/w
Action Item: Ask Ask to set up group perms and assignment of group
perms for CVS projects
Issue: Possibly reuse sourceforge code
Issue: Aegis
Action Item: Implement Aegis on top of CVS/Perforce; talk to schwern
Versioning:
Big sky issue
Larry is aware of the problem; big problem
discussed over perl6 lists; huge issue with large multinational data
centers
Apache::Auth is a bear; 3 authors, 3 releases
API Change triggers major version increase: social issue; s/b in Skud's
document
Back versions of RecDescent need older versions of Perl, and are still
supported
CPAN Filters; alternative repositories, overlaid; repository for code
work with 5.004, 5.005, 5.6.1, etc.; point at an old repository for an
old version
Module ratings
deferred to cpan-workers@perl.org
Perl6 Library
deferred to perl6-stdlib@perl.org
Topics: should Perl6 should have a standard library? What should be in
it? Requirements?
PPM:
PPM is currently a bad implementation of a great idea; AS has done a
lot work improving it recently
Look for better things to come out of PPM from ActiveState soon
PPM is a copy of the blib directory and performs a 'make install',
and does cleanup (#! paths, adding HTML docs in the doc tree)
No one has built alternative repositories of modules
Configuration in Makefile.PL? It handles ~98% of what's out there
NAPC:
Napster & CPAN
If you build something on one machine, you can give it to someone on
another machine (with a similar architecture/perl/etc.)
Once someone has built a module once, all of the QA has been done
totally opt-in
The idea is thus:
opt-in for all time, and subversively always turn on napc sharing
Sociological problems
Bell curves
target versions of perl most widely in use (business installs)
if you can help all of all the major perls being used, it is
ultimately better than fixing something moving forward
window is moving forward; help as many people as we can
Putting modules in the core only help people going forward; causes a
predjudice; reduce module dependencies in your modules, because many
users shun modules that have large amounts of dependencies; once a
module goes into the core, it's there frozen for ever (even bad
interfaces)
I don't want to rip apart MakeMaker, CPAN.pm, PPM; work around them
An idea like NAPC won't require any changes to what you're doing now;
an ease-of-use premise can be easier; nothing in the core, but
everything you need will be there
everything should be on an equal footing
issues: where an external library is installed, #! line in a script
A tarball has a unique MD5;
two MD5s; one for the system; when system MD5s are equal, the systems
are equivalent
anything I need on your system automatically installs on my system when
I need it
a master list matches up md5s of systems with md5s of tarballs; how do
we populate this list? a couple of possible trust systems you can use;
certain trusted members who haven't broken trust propogate a trusted
key; if 100 untrusted members come up with the same key, it's a trusted
key
(potential for damage where anyone can create a trusted module; cpan
has no security at the moment; if someone wants to attack the perl
community, there is no defence through cpan)
("security through not having a house": use core modules only, choose
not to download anything through CPAN)
can create a core with a trusted list (off of CD perhaps)
damian on the core: one of the issues we have is that the people who
comes to these conferences are at the high end of the bell curve; the
expectations of this set of what is easy to do doesn't mesh with the
idea of what's easy to do for the average user. CGI is in use because
the amount of work to install it is zero.
should everything in the core today be in tomorrow's core? out of the
box for perl6, you get all of the things you expect to get (great
success of Java; you get 325,000 classes that come with it; no CPAN
necessary)
the unfortunate thing about the perl5 core, it's not relevant for what
most people are doing; people don't want CGI, they want something more
sophisticated (Text::Template, Mason, etc.) it's no good that any
group sits down and determines what should be in the perl6 core because
it isn't a representive group;
need another RFC process to determine not what should be in there, but
what you have and what you use today; people want a simple life; perl
should just work
----
the number of users who can work without a core is not a minority; 10
companies on wall st., each with more restrictive environments than
most of us are used to; perl should have everything there
seething masses of perl programmers want XML::Parser, Database stuff,
and GUIs easily;
napc won't stop any process currently in use, just gives you more
options
napc is about lowering the barrier of entry for cpan modules; cpan
shell isn't required to install by hand; get rid of the stigma of using
cpan modules
buildfarms will probably fail; but if everyone is part of the
buildfarm, that would be a great success
a module in the core is in the core because it's usually very good;
core also defines standard set of modules, and tend to get used whether
or not they're the best modules to use; to know what's available, you
have to visit CPAN (and know that CPAN exists, and how to install from
CPAN)
Damian: I want to create a new modules; wanted to use filter::simple,
and not worry about putting it into a dependency file; I have to decide
what filter::simple is, and it comes along for free; that's important
(module author knows modules are on CPAN, but end-user doesn't need to
know about filter::simple)
Redesigning the core re-cannonizes what's worthwhile to be in the core;
remember that people work in snapshots; they're going to need to be
backwards compatible
Brian: if the core were to go away, it would be in about 10 years;
interfaces:
tabled
code review:
tabled
scripts:
should be really obvious to package a script as a module/distribtion
Action Item: improve module authoring tools to create scripts
modules@perl.org:
[general dissatisfaction]
upload process for new module authors kinda sucks
slow response
this is why cpan as we know it is disorganized
modules@perl.org is a lot of unfun human effort; is there any way to
get this stuff happening? Registering namespaces [automated request],
etc.
appearing in the modules list is a different issue entirely
lots of problems: what needs to be solved? shouldn't put more people
on the job (either the job sucks, or it needs more people, or...)
issues: administering cpan vs. other tasks (registering namespaces)
response has to be fast
should be tabled until TPC when people who have the power to do
something will be available
most of the problem is simply about not having enough resources; this
is not just malicious malingering; it's a thankless job, too
existing namespaces are ill-defined; need a reorganization and cleanup
of the module namespaces; done with stupid modules (ACME::*) - people
will accept the modules moving around; not that disruptive to
reorganize it
Action Item: tutorial on how to change the name the name of your module
without breaking compatibility
Action item: look at the namespaces that are there, and figure out what
they're good for (Skud)
Adding some automation should help; codify what people are doing now so
people who join can draw upon an expert knowledgebase
Action item: produce a decision tree to determine the name of a module
based on some naming guidelines (used when naming a module using h2xs)
Issue: incredible floating namespace problem
die "this module is deprecated"
module-authors@perl.org: dormant mailing list where this can be
discussed
YAS is looking at sponsoring more than just people like Damian; also
important to sponsor people who are doing the real work (maintainers,
pumpkings, patchers, etc.); perl's greatest strength and greatest
weakness is that we're all volunteers; this is not an immediate
solution, but something that is being considered very seriously.
Action item: Identify the requirements for a solution to solve
outstanding issues with CPAN
Master todo list / apprenticeship database
it would be good to have an apprenticeship database instead of a talk
at YAPC
apprenticeship would work well with the first layer of aegis
we need something better than an ad-hoc PHP collaboration tool (e.g.
sourceforge)
Mailing lists:
modules@perl.org
moudle-authors@perl.org
cpan-workers@perl.org
perl-qa@perl.org
perl6-stdlib@perl.org
perl-sdk@perl.org
cpants projects on sourceforge
