There is no good or bad, just fun and not fun

Previous Entry Add to Memories Share Next Entry
script/ local::lib
So this post was meant to be a break from the method attributes ranting, and I was going to post about local::lib.

I keep saying just use local::lib and people ask how.. And I reply just write a couple of trivial shell scripts.. And they ask how..

So I set out to provide a canonical example of how which everyone could use.

I also had read but not played with the new --self-contained feature, so I thought that would be fairly awesome. The idea of being able to say 'make installdeps', and have your entire non-core app dependency stack rebuilt was fairly cool.

I then realised, that with dhoss' helper refactor happening, making:

script/ local::lib

work is totally easy and non painful.

I started this last weekend, as a yak shaving exercise to avoid posting. Didn't prove to be quite as easy as I'd planned.

2 releases of local::lib later, I'm almost there. And when I say almost there, I mean I have a skeleton app on github with some munged scripts to do what I want, make installdeps works, I have code to inject distroprefs patches for various things (I am looking at you WWW::Mechanize), and I can build my work apps from my minicpan + injected internal code.

I haven't actually got as far as patching the preexiting scripts in script/ yet, adding 2 lines to Module::Install's Makefile.PL does what I want.

I really haven't got all that many tuits, or clues for hot to get this injected right into the generated application with Module::Install::Catalyst or whatever, so I guess I need to play with that and bug #toolchain with dumb questions some more :)

The next stage is to branch -Devel and start getting this integrated. I currently don't see _any_ solution which doesn't involve inlining my 'env' script into everyone's script/ directory - but I don't feel so guilty about that, as the code will only be executed by people running in local::lib mode, and we'll be pulling the rest of the scripts back into -Runtime soonish anyway I guess leaving them as stubs..

I'm probably likely to ignore this for a few weeks having got it thus far, as I really need to work on super sekrit project, and I have a tonne of work to do to finish the code for the stuff I'm talking about at YAPC, and I'm hoping to have a couple of live production apps deployed with it before that anyway!

So if anyone else would like to see Catalyst have native local::lib support, please please feel free to step up to the plate for anything between making it 'your baby', and just giving the current code a test-drive and docs a brush up, I'd be really grateful about now ;)

P.S. Yes, I fail at ironman, again.

P.P.S. Combining multiple roles with method attributes fails miserably. There are failing tests in my MX::MethodAttributes github fork.

P.P.P.S. I will tell you how to fix it if you care, I don't have time to hack on it.

P.P.P.P.S. Yes, I don't like not having conflict resolution either. It's still better right now than the M.I. mess I was getting into in my controllers...

local::lib and mini-cpan


2009-07-06 12:09 pm (UTC)

I'm very interested to see how this progresses. I'm in the throes of migrating from a bastardised krang-based installer to using mini-cpan and local::lib. Stuck in the early stages, so your posting has been helpful.

- ChrisH

You are viewing bobtfish