Respect envvars by cpan clis only for system perl

[krautcat]

Currently, plenv doesn't manage envvars responsible for paths where to install modules which use neither ExtUtils::MakeMaker or Module::Build. This leads to situation when setting PERL_MB_OPTS and PERL_MM_OPTS env vars to appropriate values for tuning paths where modules for system perl will be installed affects paths where modules will be installed for home-site perl interpretators maintained by plenv.

This commit introduces management PERL_M{B.M}_OPTS envvars to prevent collision and simplify maintaince modules for both system perl and home-site perl.

Signed-off-by: Georgiy Odisharia math.kraut.cat@gmail.com

[Grinnz]

I would be concerned this will break local::lib support via plenv-contrib. Why are you setting these env vars manually?

[krautcat]

Hm, yes, that's my mistake I haven't worried about this plugins.

The purpose of my efforts is to allow user to use custom path for packages of system-wide Perl interpretator.

And, for example, I set this env vars manually because I prefer to keep libraries and packages of dynamic languages (python, ruby and perl) in $HOME/.local/lib.

I think I need to design more elaborate solution.

[Grinnz]

Why I asked is that is exactly what local::lib is designed for; with a simple command you can set or unset all relevant env vars to install to and add a local directory to lib. But you can't use a local lib like this across different perls, so plenv must be aware that you're using it which is what the plenv-contrib command helps with. I'm not sure if it lets you manage a lib for system perl however.

https://metacpan.org/pod/local::lib

https://github.com/miyagawa/plenv-contrib

[krautcat]

Oh, I forgot to mention I'm already using local::lib.

When I said I set this this environment vars manually, I meant I set them via local::lib in my .zshrc/.bashrc.

When I said manually, I meant I know that plenv isn't aware of setting environment vars by local::lib outside of itself.

[krautcat]

Now I made an effort to respect env vars set by local::lib integration. Now it shouldn't conflict with plenv-contrib.

[krautcat]

@tokuhirom, any updates here?

[skaji]

I'm not quite sure what is the purpose of this PR.

People may use PERL_MB_OPTS and PERL_MM_OPTS for their own purposes. For example, they set

export PERL_MM_OPT="PUREPERL_ONLY=1"
export PERL_MB_OPT="--pureperl-only"

in their ~/.bashrc. I think this PR breaks such cases.

[krautcat]

Yes, I realized that too late. I have idea to filter env vars via regexp to exclude opts which affects paths where modules are installed. So it won't break this cases.

[skaji]

Even if they are module paths, they may be specified by end-users intentionally.

[krautcat]

I don't think any cases in which setting this vars can be helpful, only for system perl. But if you think it's overly harmful and useless I don't mind create new PR reverting this changes.

Or, for example, we can introduce new environment variable (PLENV_FILTER_PERL_MBMM_OPTS) responsible for filtering PERL_M{M,B}_OPT.

[skaji]

I don't think any cases in which setting this vars can be helpful, only for system perl.

People may use local::lib temporarily like python virtualenv:

1. exec a new shell
2. setup new local::lib environment with ./local
3. install CPAN modules (into ./local)
4. hack, test, etc
5. exit the shell

[krautcat]

But we already have local::lib integration, I've taken this into account when were developing this change.

I don't think it's good idea to ignore that extension to plenv. See ac7a13b#diff-4e72c7ded2beb5e5873ba51642dee8c8R58.

[krautcat]

@skaji, don't you mind I ask you about this PR again? I see there's no active development here but I think I don't fully understand what had you talked me about.

My work was intended to make plenv shims to take into account environment variables in two cases:

1. env vars set by user for system-wide perl;
2. env vars set by plenv-contrib helpers.

For the first one I test whether current perl version is system or not. If perl version is system, then user is responsible for maintaining the variables. User can use them for any purpose they want. And for the case you have mentioned earlier (like python virtualenv). So if this variables are set and current version is set to system, shims don't touch env vars responsible for module installation.

For the second one my shims unset environment vars that could be previously set by .zshrc/.bashrc/etc if and only if current perl version is not system, so it's maintaned by plenv, and env vars doesn't seem to be set by local::lib integration for plenv (it's tested via PERL_MM_OPT var). This is made to install modules to default path of perl interpreter maintained by plenv. Otherwise, if env vars seems to be set by plenv-contrib integations, we do nothing.

About your example. plenv-contrib integration is exactly what plenv already offers to users want virtualenv-like behaviour for perls maintained by plenv. So if user want virtualenv-like things for perls installed and maintained by plenv, he/she should use plenv-contrib.

Why am I thinking that unsetting sensitive variables is OK in case when current perl version is plenv maintained and variables doesn't seem to be set via plenv-contrib integration? I think so because if project offers some extras users should use them and don't reinvent the wheel.

The main question is should we give to user maximum freedom in manipulation important variables or not. If yes, my changes must be reverted. But if we suppose that such cases is covered by plenv-contrib integrations and user shouldn't go against it, then my work seems legit.

There is a choice between compatibility with local::lib integration with system-wide perl installation and between maximum users' freedom. My code said that I had chosen the first. But again, If there's something wrong with my opinion, I am open to long-term discussion. Anyway, my goal is not to make my life easier while complicating it for others. I introduced my changes with the consistency of project in mind. Not from start of my work but I had come to it later.

[Grinnz]

The main question is should we give to user maximum freedom in manipulation important variables or not.

We should not. User-set local::lib variables will be wrong for all plenv-managed perls in 99% of cases. The remaining 1% already will know how to set it up correctly.

[krautcat]

So is it ok to let plenv-created shims cere about user-set local::lib variables in case when the current perl version is system? If yes, is there any obstacles to my work in the direction of simultaneous coexistent local::lib integration for plenv-managed perls and local::lib support for system-wide perl? Of course, this shouldn't break anything for plenv-managed perls. my commits should affect only system-wide perl.

[Grinnz]

I think it is reasonable to assume that user-set local::lib variables are intended to be used with the system Perl; if it is not so, the user should know how to fix their environment. We need to optimize for the common cases, because otherwise they will break and those users are less equipped to understand the problem.

[skaji]

As I said, PERL_MM_OPT and PERL_MB_OPT are not only for local::lib. https://github.com/tokuhirom/plenv/pull/135#issuecomment-415545776

I think we should revert this change.

[skaji]

@tokuhirom What do you think?