PortGroup directory hierarchy/priority

[Joshua Root]

On 2016-6-1 03:34 , Mojca Miklavec wrote:
> On 27 March 2016 at 17:33, Rainer Müller wrote:
>> On 2016-03-27 16:57, René J.V. Bertin wrote:
>>> Can someone please summarise the exact priority rules used in
>>> resolving the file to be included when using a PortGroup statement in
>>> a port?
>>
>> 1. _resources/port1.0/group/*.tcl in ports tree of this port
>> 2. _resources/port1.0/group/*.tcl in default ports tree
>>
>> This is here in the base source:
>>
>> proc PortGroup:
>> https://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl?rev=147064#L2561
>>
>> porc getportresourcepath/getdefaultportresourcepath:
>> https://trac.macports.org/browser/trunk/base/src/macports1.0/macports.tcl?rev=147103#L1637
>>
>> The _resource directory is meant to contain files that are specific to
>> this ports tree. This allows local modifications to port groups in a
>> ports tree without influencing other ports trees.
>
> Can you please explain if the following behaviour is intended by
> design or if it is a bug?
>
> "port something portname" works like you describe
> "port something ./[path/to/]portname" uses the default portgroup
>
>
> A concrete example. I modified livecheck in the perl5 PortGroup in the
> local svn checkout. Then I tested the following:
>
> $ cd /path/to/local/checkout
> $ portindex
> $ port -d livecheck perl/p5-b-c # uses *global* resources
> $ port -d livecheck perl/p5-* # uses *global* resources
> $ cd perl
> $ port -d livecheck p5-b-c # uses local resources
> $ port -d livecheck p5-* # uses local resources
> $ port -d livecheck ./p5-b-c # uses *global* resources
> $ cd p5-b-c
> $ port -d livecheck ./ # uses local resources
> $ port -d livecheck # uses local resources
>
> These examples seem somewhat strange to me.

It's more like a limitation of the information that is available when 
you parse an arbitrary Portfile, whether implicitly using the current 
directory or specifying a path. You don't even know the port's name 
until you parse it once. If you're not going via the PortIndex, you 
don't know what repo (if any) it belongs to and thus whether it has any 
local resources. So the default ones get used.

I guess with enough effort you could figure out when some arbitrary path 
is inside a sources.conf repo, but is it worth it when you can easily 
fix the problem by looking up via the index?

Cf. also <https://trac.macports.org/ticket/15186> which is sort of the 
opposite problem.

- Josh