hack'a'day :accessing macports:: variables from a PortGroup

[Clemens Lang]

Hi,

On Mon, Oct 23, 2023 at 01:41:23PM +0200, René J.V. Bertin wrote:
> This is probably seen as a forbidden hack, but is there a way to
> access variables from the macports namespace in a PortGroup (or
> Portfile)?
> 
> I know that "user" code like this is executed under/through
> `mportopen` which is in that namespace, but when I invoke `namespace
> children` I only see (all?) other namespaces.

This isn't possible. The code in mportopen isn't inside a namespace,
it's inside a separate Tcl interpreter, which does not have the
macports:: variables you want to modify.

Only specific variables and procedures are exposed to the Portfile
context using aliasing, so the things you can change in MacPorts base
from a Portfile are limited. This is a good thing, because we really
really don't want a port to affect how any of the ports processed in the
same invocation afterwards are installed.


> Use case: I'd like to set `revupgrade_autorun` to false under very
> specific circumstances.

I'm not aware of any problems with rev-upgrade other than the
weak-linking thing to which there is a fix in a PR, which I'll probably
merge soon.

Every other binary that I've encountered that fails rev-upgrade is
broken, so unless you are using weak linking, may I suggest that you
instead fix the binary you're installing in your Portfile? A broken
binary is of no use to users, and we have tools to fix the load paths of
libraries should that be the problem.

-- 
Clemens