env_helper

[Bradley Giesbrecht]

On Mar 16, 2009, at 11:17 AM, Rainer Müller wrote:

> On 2009-03-15 23: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).
>
> Okay, so you expect this to be added to PATH. At the front? At the  
> end?
> In which order?

Front, and yes, the order isn't guaranteed to be correct for everyone,  
especially all those people installing mysql4 and mysql5 :)

> How will it now it needs to do concat at all and not replace?  
> (Thinking
> of possible more general settings). How will it know to concat using  
> ":"
> and not spaces?

Because everything in etc/env_helper/paths is going to be parsed and  
have it's paths added to the front of the var value with ":" as the  
separator.
Different things could be done in /etc/env_helper/vars as an example.

I know this is not a robust solution. I'm just looking for a one liner  
to be added to ~/.profile to fix some of the things that don't work,  
like apache2 and mysql5 you mention below.

> For apache2, this is just the old lame reason that nobody fixed the
> layout yet to be inside $prefix :-)

Agreed :)

> mysql5 does not put the files into $prefix/bin because it conflicts  
> with
> mysql4. If now both ports add the alternative dir to PATH this lends  
> to
> confusion and breakage.

Agreed. This multi-version idea doesn't seem to pay well. Any chance  
of a refund :)

> For example, you installed mysql4 which has added the libdir to PATH
> this way. Typing "mysql" is actually mysql4. Now some port also  
> pulls in
> mysql5 which you do not recognize at all and suddenly "mysql" is  
> mysql5
> because for some reason the PATH ended up in this order.
>
> By the way, can anybody think of other ports we did not talk about yet
> for which something like this could be useful? For example, I can  
> think
> of bash-completion.

I have a bash-completion line in my ~/.profile as well.

> I concur with Jeremy that a equal sign separated format would be the
> better choice for this, for clarity and maintenance, one file per port
> is enough.

And I have no objection to this either. While working on the perl5 fix  
I learned about path_helper and thought throwing something simple  
together to get a ~/.profile one liner might be useful.

I also imagined that for those whose env ended up not being what they  
wanted they could not use the one liner OR they could toss their own  
file into the proper dir and override or what ever. Just name the file  
so it gets read last.

> What I would like to see is a way to choose which items
> are actually added to my environment, because I still want to have
> control.

Wouldn't making overrides solve your control issue?
I'm just thinking something very simple that works 93% of the time. If  
your in the 7% you'll know how to quickly fix up your env I bet.

> I think the easiest would be to use symlinks. I have a layout
> in mind similar to what is used for init-scripts on most systems.

And I consider symlinks clutter :)
Simlinks would be much more time consuming to track down and modify if  
you weren't happy with the choices that were made for you.

> To address the issues mentioned above and support a little bit more we
> would have to split it into env and profile:
>
> ${etcdir}/env-avail.d/:
>  apache2
>  mysql5
> ${etcdir}/env.d/:
>  apache2 -> ../env-avail.d/apache2
>  mysql5 -> ../env-avail.d/mysql5
> ${etcdir}/profile-avail.d/:
>  bash-completion
>  trac-tools
> ${etcdir}/profile.d/:
>  trac-tools -> ../profile-avail.d/trac-tools

This sounds good but personally I'd vote to just have them all add and  
allow overrides. If overrides aren't cutting it then just don't  
include the ~/.profile one liner and setup your on env. I'll bet this  
will be the rare exception.

> (Think of trac-tools making [1] available, as I can't think of another
> existing port right now).
>
> env.d is meant to contain files in the equal sign separated format  
> which
> are concatenated. Rules for concatenation are The order has yet to be
> defined (possible using 00foo through 99bar in the symlinks?).

And have Portfiles deciding when they are loaded. I see a lot of  
99999myports.

[...]
> port env --update
>  Generates or updates ${etcdir}/profile based on the current symlink
>  layout, which is then used by `port env` as traversing all the files
>  each time a shell is spawned is probably a bit slow. Could also
>  generate ${etcdir}/profile.csh or similar. Needs to be run
>  after --enable/--disable or port installes/upgrades to apply changes.
>  Ideally port would check for file modification time of ${etcdir}/*.d/
>  after activation and recommend to run env-update if necessary.
>
> A user would only need to add this line to his .profile to load  
> MacPorts:
>  [ -f /opt/local/etc/profile ] && source /opt/local/etc/profile
>
>
> Still reading? Comments? ;-)

I am not familiar with the port code base but I do think that if ports  
are allowed to install things in dirs that are not already in ones  
typical paths and such the port should have a way and a responsibility  
to fix up the env.

>> [...]
>> This can probably be done better but I do think this adds value with
>> little cost.
>
> This will definitely be useful, especially as it reduces the need of
> lines to be added to the profile. I started something different for  
> this
> earlier with $prefix/share/macports/setupenv.bash in which nobody  
> seemed
> to be interested (e.g. similar scripts for tcsh/zsh). But this could  
> be
> incorporated into the new ${etcdir}/profile.

I think fixing the location or env for ports shouldn't cost all that  
much and pays for itself quickly.

Whichever the approach is taken I think the conf files should be  
constructed so as to be easily parsed by shells other then bash. I use  
bash but I think we should be kind to others and it shouldn't be that  
difficult.

As well, I would like to have it easily overridden with /etc/$ 
{somedir}/override or /etc/${somedir}/user or something. This way if  
you need to tweak something you can still take advantage of the env  
setup but alter a little at the end. If you need major changes just  
don't use it and tweak your ~/.profile.

Thank you Rainer and Jeremy for expressing an interest in making the  
macports env more friendly.


//Brad