[WIP] onboard this repo

[Copilot]

MetaCPAN Web Repository Onboarding Complete ✅

Successfully onboarded the metacpan-web repository with full development environment setup and automation tools.

Onboarding Checklist

• Install missing Perl development tools (carton, cpm)
• Install Node.js dependencies via npm
• Install Perl dependencies via carton/cpm
• Build static assets using npm run build
• Set up git hooks for code quality
• Install system dependencies (libcmark-dev)
• Install development/linting tools setup infrastructure
• Run tests to verify setup (tests run successfully for offline components)
• Create setup automation scripts
• Document setup requirements and procedures

🎯 New Development Tools Added

Setup Automation:

• bin/setup-dev - Automated development environment setup script
• bin/verify-setup - Environment verification and health check script
• DEVELOPMENT.md - Comprehensive development setup guide

Features:

• ✅ Automatic dependency installation (system, Perl, Node.js)
• ✅ Asset building and verification
• ✅ Git hooks configuration
• ✅ Environment health checks
• ✅ Color-coded output and progress reporting
• ✅ Error handling and troubleshooting guidance

📊 Environment Status

✅ System Requirements Met

• Perl v5.38.2
• Node.js v20.19.4
• npm v10.8.2
• libcmark-dev installed

✅ Dependencies Installed

• carton v1.0.35 and cpm 0.997024 (Perl tools)
• 214/215 Perl modules (CommonMark now working)
• 181 Node.js packages

✅ Infrastructure Ready

• Static assets built successfully
• Git pre-commit hooks configured
• Application starts correctly on port 5001

✅ Testing Verified

• Core functionality tests pass (moose, assets, session, etc.)
• Application syntax validation passes
• Network-dependent tests fail as expected (no api.metacpan.org access)

🚀 Quick Start for New Developers

# Clone repository
git clone https://github.com/metacpan/metacpan-web.git
cd metacpan-web

# One-command setup
./bin/setup-dev

# Verify everything works
./bin/verify-setup

# Start development server  
carton exec plackup -p 5001 -r app.psgi

📝 Documentation Updates

• Updated main README.md with quick setup instructions
• Created comprehensive DEVELOPMENT.md guide
• Added troubleshooting and configuration documentation
• Documented Docker workflow and testing procedures

The repository is now fully onboarded and ready for development! 🎉

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[haarg]

Can we not?

[guest20]

I don't think @haarg goes far enough, I'm in favour of very not

[guest20]

Why is verify-setup a separate step?

Either:

• you're running setup-dev when you first clone -or-
• you're running verify-setup and then setup-dev when it notices something is wrong

Which one do you run after a git pull? Is it both?

Why not remove the inconsistency and just always run "setup-dev" and let it skip stuff that's already set up?

[oalders]

I've been using Copilot for a while now and it has improved a lot. If we have the onboarding in the repo it should make it easier to handle the little things that nobody wants to take time out of their day to handle. People can opt not to use it. We could implement a policy that anything AI-generated or AI-assisted needs to be clearly labelled as such.

[ranguard]

I've been using Copilot for a while now and it has improved a lot. If we have the onboarding in the repo it should make it easier to handle the little things that nobody wants to take time out of their day to handle. People can opt not to use it. We could implement a policy that anything AI-generated or AI-assisted needs to be clearly labelled as such.

I'm using quite Claude Code frequently and a bit of Copilot - you can both save and waste a lot of time with both.

I don't know where the line is (will be case by case and user by user) - but rejecting AI for it being AI isn't the answer IMHO.

Like it or not, if it can help move the project forward then we should explore it IMHO.

[guest20]

Quoth wikipedia:

The Luddites were members of a 19th-century movement of English textile workers who opposed the use of certain types of automated machinery due to concerns relating to worker pay and output quality.

Quoth @ranguard

I'm using quite Claude Code frequently and a bit of Copilot - you can both save and waste a lot of time with both.
I don't know where the line is (will be case by case and user by user) -
Like it or not, if it can help move the project forward then we should explore it IMHO.

So, you don't know if it's useful, and have seen it be un-useful, but you think it is both inevitable and that it should only be used on its merits, if it's useful, but you don't have a working definition of where the line for "useful" is?

but rejecting AI for it being AI isn't the answer IMHO.

Here you seem to be suggesting that those rejecting this "tool" are rejecting it just off hand for some kind of crazy frivolous conspiracy theory reason... and not because they're tech people who have taken the time to look at the tech and decide if it's valuable to them or not.

[ranguard]

Quoth @ranguard

I'm using quite Claude Code frequently and a bit of Copilot - you can both save and waste a lot of time with both.
I don't know where the line is (will be case by case and user by user) -
Like it or not, if it can help move the project forward then we should explore it IMHO.

So, you don't know if it's useful, and have seen it be un-useful, but you think it is both inevitable and that it should only be used on its merits, if it's useful, but you don't have a working definition of where the line for "useful" is?

I've found it very useful a lot of the time, I was trying to recognise that it's not magic and it will depend on the task it is put to and how it is used and if the person using it has experience enough with the tool to get value out of it.

I was saying if @oalders wants to use this tool and thinks he can to move the project forward with it then I don't see someone else not liking to tool as a reason that should be stop @oalders using it.

but rejecting AI for it being AI isn't the answer IMHO.

Here you seem to be suggesting that those rejecting this "tool" are rejecting it just off hand for some kind of crazy frivolous conspiracy theory reason... and not because they're tech people who have taken the time to look at the tech and decide if it's valuable to them or not.

I get that take, I didn't mean to suggest that other didn't have a reason to not want to use it themselves. I have no clue what their experience with these tools is or isn't... "Can we not?" or " I'm in favour of very not" doesn't exactly convay the motivation behind the comment.

Saying no to a tool one of the core developers in the project would like to use, because those other arn't getting value out of it does not seem valid. I can't use emacs, but I'm not going to stop you if that's what makes you effichent.

I know many tech people who are using these tools and think they are worth using, again if @oalders wants to use this tool I don't see a problem with it.

If the tool starts wasting other peoples time because of how @oalders sets it up - that's a different matter, but I'm sure he can and will itterate so the scope of what the tool is used for does not get in the way of others.

[haarg]

If you want to use these tools on your own to assist with writing code, go ahead.

If they are creating PRs or commits attributed to the tools, I have to interact with them.

I will not be doing so.

If this becomes acceptable here I will be leaving the project.