Implement Carton::Setup (was: PERL_CARTON_EXEC) #82
Conversation
|
I do understand the motivation/use case but am not sure if that's the best way to handle this. Re-running carton exec inside your app can lead it to the infinite loop easily by a simple misconfiguration. I think what you want to do can be done in two separate steps, one is to ensure that the script must be loaded from carton exec, like bundler's The other is to provide an easy way to generate wrapper/shim scripts (like binstubs) so that the user of your code can run as a standalone script without prefixing them |
|
@miyagawa: gotcha. so I've now removed my previous commit, and replaced it with a new module, Carton::Setup. This is a hack atm, but can you check and let me know if I'm in the same wavelength as you? https://github.com/lestrrat/carton/commit/b855ef191fd32d00c5b95fab5e95408f1c96e84a |
|
Yeah, looks sane, unless @masaki disagrees. |
|
I agree to Carton::Setup. I think it's a good change, will be easier to implement |
|
I haven't looked at the details, and I'm not asking you @lestrrat to update the code (yet :D), but what happens if you run the script with |
|
Yeah i guess you can de-duplicates the INC path, and setting that up twice is acceptable. I plan to eliminate lib::core::only for the runtime, at least not by setting them to PERL5OPT since that will affect the subprocesses that are not meant to be run with carton. |
* Changed functions to be called via $class->setup() et al, so juuuuuust in case somebody was crazy enough to want to change the semantics of Carton::Setup, they can. * Added docs
|
@miyagawa @masaki : I didn't know how exactly the plan to eliminate lib::core::only was going to be carried, so I punted it for now, and added more thorough docs. As noted in my previous message, only PATH gets a bit icky in case you do 'carton exec' (but shouldn't really affect anything), so I left it as is too. If you have any other concerns, please let me know and I'll get on top of them. Otherwise, I'll wait for review/merge. |
…PERL5LIB. Re: #82 #70 #60 PERL5LIB isn't perfect since it doesn't eliminate site_perl from @inc in the child process, which means carton exec could accidentally load modules from site_perl even when they are not available in the carton.lock. We'll address this by either implementing a check-like logic in the exec (which would add an overhead), or add some additional @inc hooks in the development, which can detect such errors, a la App::FatPacker
|
👍 on this |
Scenario: You have a legacy app that is now carton-ized. You have a bunch of scripts that don't use carton, and you can't expect people in your teamto explicitly call "carton exec -- script.pl". So you want to re-execute these scripts via carton and set the right paths when somebody casually does "./bin/foo.pl".
This change allows sets $ENV{PERL_CARTON_EXEC} variable to true, so called scripts can detect if it has been dispatched via carton or not.