python PortGroup and destroot.pre_args

Ryan Schmidt ryandesign at
Fri Jul 2 13:20:11 UTC 2021

On Jul 2, 2021, at 05:51, René J.V. Bertin wrote:

> On Friday July 02 2021 04:31:50 Ryan Schmidt wrote:
>> If I create a dummy portfile that includes the python portgroup then then immediately tries to print destroot.pre_args, it shows why it failed:
> Yes, I followed that much.
>> The real question is why do you need to access destroot.pre_args right after including the python portgroup and before setting name?
> No, the real question is in reading the one I asked a little bit less literally:

Well I can't guess what your real question was; I can only answer the ones you ask.

>>> Why would `name` have to be defined in order to be able to evaluate destroot.pre_args ?
> i.e. why would you do anything in a Portgroup that introduces this side-effect. For instance, can't whatever it does be done in a pre-destroot block, or via a callback (using a function that ? 

I am not certain whether changing that would introduce new unwanted side effects. The python portgroup is included in a *lot* of portfiles, so it might be difficult to verify that a change doesn't break one of them.

> To answer your question: this came up because of a `destroot.pre_args-prepend -v` statement I added to another Portgroup (local copy of the meson PG I've been trying to improve). It seems perfectly reasonable to ensure (via its dedicated PG) that a build system uses verbose mode in a build phase.

By the same argument as in the preceding paragraph, you could do your `destroot.pre_args-prepend -v` modification in a pre-destroot block.

> I've worked around the issue by doing the prepend only when the Python PG hasn't been included (I could have added "and `name` isn't set yet) but it'd be really nice if PGs tried their best to interfere least with others...

They do. Sometimes situations, like the one you encountered, aren't anticipated.

More information about the macports-dev mailing list