Architectural issues with absorbing Gitpan

[schwern]

This is to discuss some general issues about MetaCPAN taking over Gitpan before I go too deep.

I've gotten what I wanted out of Gitpan, so I'm happy to hand it over for group maintenance. Also probably 70% of Gitpan is redundant with MetaCPAN and it's mostly the 70% I'd like to get rid of. Because of that, rather than keep it as a stand alone project I'd rather it was fully absorbed into MetaCPAN.

Here's some of the high level issues with merging the two projects.

• Logging
  • MetaCPAN's is better overall
  • Gitpan's is friendlier, better for unit testing
  • I'm pretty sure I can pull the best parts of Gitpan's logger into MetaCPAN.
• Moose (MetaCPAN) vs Moo (Gitpan)
  • They'll work together, but using different type systems is a problem.
  • I've come to prefer Moo (in particular Type::Tiny)
• Path:Class (MetaCPAN) vs Path::Tiny (Gitpan)
  • I've come to really like Path::Tiny
  • Switching MetaCPAN to Path::Tiny doesn't look hard (it doesn't appear to use Path::Class much)
  • Switching Gitpan off Path::Tiny will be harder (it uses Path::Tiny a lot)
• Harmonize types
  • I've come to prefer Type::Tiny.
• Harmonize tests
  • They fake CPAN interaction differently (Gitpan checks in the file tree, MetaCPAN builds it)
• Indexing
  • MetaCPAN indexing is tolerant to out of order indexing, Gitpan is not
• Gitpan uses perl5i
  • It's baked in pretty deep.
  • I'd very much prefer to keep it.
  • It's effects are lexical, so there should be no problem if Gitpan uses it.
  • It has a lot of dependencies.
• Gitpan uses Method::Signatures
  • It's baked in really deep.
  • I'd very much prefer to keep it.
  • It throws off line numbers and there's no fix.

I'm sure there's more, but that's what I can think of off the top of my head.

[oalders]

Logging: I'm not attached to how we do logging in MetaCPAN. I don't think we log much of anything to disk right now and I wish that would change. We had talked about Log::Dispatchouli at one point. I'm not familiar with Gitpan's logging.

Type systems: I really like Type::Tiny and I'd have no issue with making the switch.

Path::Class vs Path::Tiny: I don't have a strong opinion, so Path::Tiny works for me.

Tests: @rwstauner may have some thoughts on this

perl5i/Dependencies: not a problem. Introducing perl5i into other parts of MetaCPAN make make the learning curve even steeper, so if we can isolate it to the Gitpan parts, that might be best.

Method::Signatures: see perl5i above

[schwern]

I've found a fix for Method::Signatures messing up lines, I can use either Kavorka or Function::Parameters which don't rely on Devel::Declare and instead use PL_keywords. That will raise the minimum version to 5.14. If that's acceptable I'll do that change in Gitpan before switching over.

perl5i is lexically/package isolated so there's no problems there.

Gitpan's logging is very simple, it just writes to a file for each distribution, so that's not very good. The main advantage is the logging configuration takes care of setting itself up. Gitpan's configuration file has an overlay system so one config file can contain both good production defaults as well as a testing defaults (see "overlays" at the bottom of this config file). This is probably overkill, an include system would work better, but you get the idea. Point is, you don't need to do special work to instantiate the logger, it will read what it needs from the config file.

Gitpan also has a single test wrapper Gitpan::Test which takes care of configuring the test environment, providing any extra test functions, providing a standard set of testing modules, and ensuring everything cleans up after itself. Something like that for MetaCPAN would help... if it doesn't already exist and I just can't find it.

[oalders]

Raising the minimum Perl version is fine. In production we use 5.18.2

[ranguard]

Nothing happened in a long while, closing