With Dancer 1, it's possible to do that:
Where lib/SomeApp.pm exists.
It doesn't work anymore (used to work) with Dancer2. Apparently, it's a deliberate choice: 7ae4eab
The commit message here is not very explicit about the reason why we break that. I'd like to understand the rationale behind.
Was it causing any hurt somewhere?
I think it was a good thing to have and would like to understand why we got rid of it.
Thanks for the clarification (and sorry if I missed an email/discussion about that).
This is something we've set to revert. It was a mistake. We could push this to be out this weekend.
Is this related also to #478?
/me bangs his head.
@xsawyerx okay, then let's put it back on stage when we can :)
Ok, I'll patch that one and release, we need it to be fixed, I just realized it also breaks with a scaffolded app.
Fix issue #481 - include local lib by default
When the worker starts, it will always add the local ./lib directory in Perl's
given app.pl is now doing the 'use lib' I can't see why Dancer2 should do that. Modifying @INC should be explicit - 05e3118 seems like a step back to me, since it means that if I do e.g.
use lib "/some/path/to/my/app";
in a script, the script could break depending on the current working directory, which seems utterly horrible.
I concur with @shadowcat-mst seems to me like app.pl is enough. Whilst I realise this breaks existing apps with old app.pl scripts, it seems like 0560955 is the better solution.
Okay then, let's put that responsibility on the runner script.
Change to be reverted and documented.
Revert "Fix issue #481 - include local lib by default"
This reverts commit 05e3118.
Can we now close this?
Time to close this.