PR pkg/46570 infelicities in pkglint

"A good start would be rewriting it not in perl."

PR pkg/46570 infelicities in pkglint

"A good start would be rewriting it not in perl."

Things You Should Never Do, Part I

"When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."

PR pkg/46570 infelicities in pkglint

"A good start would be rewriting it not in perl."

Things You Should Never Do, Part I

"When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."

"It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time."

Local git

$ echo .git >> ~/.cvsignore
$ echo CVS >> ~/.gitignore_global
$ cd $PKGSRCDIR/pkgtools/pkglint
$ git init
$ git add .
$ git commit -am 'Add pkglint to git for offline hacking.'
$ git checkout -b rehab

$ cd $PKGSRCDIR/pkgtools/pkglint
$ git checkout master
$ cvs update
$ git commit -am 'Track upstream changes from pkgsrc CVS.'
$ git checkout rehab
$ git rebase master
$ vi files/pkglint.t files/pkglint.pl && make test && make clean
$ git commit -am 'More cool stuff on my branch.'

I've been writing a lot of Perl lately

I know a way to revive legacy code

Test-Driven Development

• Misnomer!
• Design technique (happens to result in automated tests)
• Programmer documentation (happens to be executable)

TDD leads to code that looks like it was written by someone careful, skillful, and tasteful.

"Test-Eventually Development"

• We didn't write pkglint test-first
• Design suffered
• Programmer documentation suffered

Whether or not we decide to rewrite pkglint, first we have to understand and document its current behavior.

Never too late to test first. Just a bit more difficult.

In pkgsrc-current

• Convert to "modulino"
• Add a test script
• Hook it up to make test (just barely)
• Write a few tests (very simple)
• Prove that they fail when they should

Approved-by: wiz

In my git

• Add "characterization tests" over a few mature packages
• Extract some Perl classes to separate files
• Fix make test (no custom settings needed)
• Deepen an existing test to prepare for refactoring
• Change huge if/elsif/else block to dispatch table
• Fix a bug (!) found during refactoring

Planning to merge to pkgsrc. In the meantime, see GitHub.

pkglint isn't such a big deal

pkgsrc/mk is

pkglint isn't such a big deal

But pkgsrc/mk is

Gradually...

• Cover infrastructure code with automated tests
• Gain shared understanding of complex internals
• Freely and safely change them for the better
• Keep what makes pkgsrc special
• Push pkgsrc forward

"Never too late to test first"

• Tangle of implementation languages
• Tangle of dependencies
• Progress won't be fast
• The alternative is worse
• We'll have to work together
• We'll have to be patient and persistent