python PortGroup and destroot.pre_args

[Ryan Schmidt]

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.