env_helper

[Bradley Giesbrecht]

On Mar 15, 2009, at 7:21 PM, Jeremy Huddleston wrote:

> I think this is a bit too many files lying around.

I really don't understand what the implied problem is here. Can you  
explain?

I simply took the path_helper approach and modified the script to  
figure out the var name based on the file name so I would have to  
modify the core script if lets say perl5 wanted to add PERL5LIB.

> Why have separate directories/files for each environment variable.

That's the way path_helper does it.

If it ends up being a port then this port could right the initial  
paths but other ports would need to write their own vars like mysql  
wouldn't own the file.
If this was built into macports then macports could manage it and have  
some new commands for Portfiles to write user env vars.

As I think I mentioned, this is only for paths right now. I have this  
as env_helper/paths because I'm looping and concatenating with ":" as  
a separator. Concatenating with ":" wouldn't be appropriate for other  
vars.

I planned on a generic ENVIRONMENT_VARIABLE=VALUE under env_helper/vars


> It seems cleaner to me to have:
>
> ${etcdir}/paths.d contain a set of files (one file per port).  These  
> files are newline-delimited in the form:
> ENVIRONMENT_VARIABLE=VALUE
>
> so you would have:
>
> ${etcdir}/paths.d/mysql contain:
> PATH=/opt/local/lib/mysql5/bin
>
> ${etcdir}/paths.d/perl5 contain:
> MANPATH=/opt/local/share/p5/man
>
> It would be nice to actually have this be backwards compatible with  
> path_helper, so if ${etcdir}/paths.d/myapp contained:
> /opt/local/lib/some/bin
That's what my script does now. paths.d is renamed PATH.d but that's  
the only diff. The files in PATH.d can be written exactly like  
path_helper files or they CAN use ${PREFIX} so the ports would use the  
system could have pre-written support files that would just be copied  
in place.


So you would parse the file into left and right side values and add  
them to the beginning of the current env var?
echo $PATH
/sbin:/bin
becomes
/opt/local/lib/mysql5/bin/sbin:/bin


This is obviously doable but it's more work then I wanted to put into  
it before I knew whether or not there is even an audience.

> it would default to assume an implicit PATH=.  Similarly, it could  
> support ${etcdir}/manpaths.d with an implicit MANPATH
>
> I thought about that last year, but I never got around to doing  
> anything about it ;)

If you or someone wants to contribute parsing left and right of equal  
into vars go ahead and I'll support that.

The thing is, when you have ENVIRONMENT_VARIABLE=VALUE how are you  
going to know whether or not you should prepend current var values  
with the new value and a path separator. I think your script wound  
have to be smart enough to know what to do with names. By having a  
path TYPE var we can drop anything in this dir and treat it the same  
knowing nothing about the var name. I don't need to know what PERL5LIB  
is used for, it's in the paths dir, I'm going to concat with sep.

> On Mar 15, 2009, at 15:25, Bradley Giesbrecht wrote:
>
>> I'm thinking I like this.
>>
>> I just added paths for ${PREFIX}/apach2/bin and ${PREFIX}/lib/ 
>> mysql5/bin to /opt/local/etc/env_helper/paths/PATH/(apache2 &  
>> mysql5).
>>
>> So port apache2 and mysql5 could add /opt/local/etc/env_helper/ 
>> paths/PATH/apache2 and /opt/local/etc/env_helper/paths/PATH/mysql5  
>> during install and with the one line added to .profile you pick up  
>> their bin dirs.
>>
>> I've done the same for MANPATH where I installed p5 man pages to / 
>> opt/local/share/p5/man. The p5 module man pages show up first, then  
>> the port perl5.8 base modules and then the apple perl5.8 man pages.
>>
>> This can probably be done better but I do think this adds value  
>> with little cost.
>>
>> //Brad
>>
>> On Mar 15, 2009, at 2:26 PM, Bradley Giesbrecht wrote:
>>
>>>
>>> On Mar 15, 2009, at 1:28 PM, Bradley Giesbrecht wrote:
>>>
>>>> I have modeled an env setup script after the one apple supplies  
>>>> at /usr/libexec/path_helper which is evaluated by /etc/profile.
>>>>
>>>> My idea is to add a line like this at the top of ones .profile  
>>>> file.
>>>> eval `/opt/local/libexec/env_helper`
>>>>
>>>> I don't know if this list allows file attachments so if the tar  
>>>> file is not attached I will upload it somewhere and send another  
>>>> email with a link.
>>>> If I should open a trac ticket someone tell me to and I will.
>>>>
>>>> I was thinking this might be a nice way to allow ports to modify  
>>>> the users env in a managed fashion. They can drop their env files  
>>>> in the proper place and they will be automatically added to the  
>>>> users env.
>>>>
>>>> Also, since the files would be registered to the port if the port  
>>>> is deactivated the files can be removed.
>>>>
>>>> I was thinking of making this as a port (env_helper or  
>>>> macports_env) that other ports could use or if people thought it  
>>>> useful adding it directly to macports.
>>>>
>>>> I started with just path vars and only bash at this point but  
>>>> looking at /usr/libexc/path_helper it shouldn't be difficult to  
>>>> add support for other shells.
>>>>
>>>> I'm simply naming the files the same as the env var and looping  
>>>> over the directory.
>>>>
>>>>
>>>> //Brad
>>>
>>> I modified /opt/local/libexec/env_helper to evaluate the paths so $ 
>>> {PREFIX} can be used in the conf files. This would not NEED to be  
>>> done because any installer could create the path properly but it  
>>> does remove that necessary step.
>>>
>>> //Brad
>>
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>