PortGroup github 1.0 shouldn't set name in subport

[dliessi (Davide Liessi)]

github.setup sets the port name to the project name (among other things).
This causes troubles if the instruction is used inside a subport, namely the subport is not found by 'port'.

Setting name ${subport} after github.setup causes an error with 'port lint' (port name and directory name mismatch).
A workaround is set PortInfo(name) ${subport} (see also the definition of 'proc subport' in portutil.tcl).

The solution would be to conditionally set name only when github.setup is not used in a subport, since the subport name is already set.

An example where this problem arises can be seen in attachment:Portfile.9:ticket:40139​.

(Cc: ryandesign because he's the one who created the PortGroup and did most of the changes.)

[ryandesign (Ryan Carsten Schmidt)]

Yes I've noticed some ports needing to go to unusual lengths when the github portgroup is used in a subport but not in the main port. I did not anticipate this usage pattern when creating the portgroup.

I'm open to a change to the portgroup that would set name only if it isn't already set.

Perhaps the bitbucket portgroup (which was based on the github portgroup) needs a similar change.

[dliessi (Davide Liessi)]

I tried different things, but the only one that worked as I wanted was the workaround I already implemented in attachment:Portfile.9:ticket:40139​​.

[dliessi (Davide Liessi)]

(Just in case you are following the ticket updates only through email, I uploaded a patch.)

[dliessi (Davide Liessi)]

The new version of the patch works better: it does what I originally thought (set name only when it is necessary, instead of fixing it when it isn't) and takes into account the case of a port with a different name than the github project name (if you set name before github.setup, the name won't be overwritten).

Can you review this?

[raimue (Rainer Müller)]

In my opinion PortInfo is an internal data structure and should not be used by Portfiles. Can't we check if we are in a subport with $subport != $name as we already do in other Portfiles?

[ryandesign (Ryan Carsten Schmidt)]

Why does this need to be any more complicated than changing

name                ${github.project}

to

default name        {${github.project}}

?

[dliessi (Davide Liessi)]

Replying to raimue@…:

In my opinion PortInfo is an internal data structure and should not be used by Portfiles. Can't we check if we are in a subport with $subport != $name as we already do in other Portfiles?

I did try many things that I saw in other Portfiles, including this, but they either didn't work or gave errors with port lint. In this case, I wasn't able to access name from the PortGroup file when github.setup is used inside a subport.

Replying to ryandesign@…:

Why does this need to be any more complicated than changing

name                ${github.project}

to

default name        {${github.project}}

?

This seems to work. Are the external {} really necessary? I can't see any difference here.

[dliessi (Davide Liessi)]

use default name

[dliessi (Davide Liessi)]

I upgraded the patch according to Ryan's suggestion.

[ryandesign (Ryan Carsten Schmidt)]

Replying to davide.liessi@…:

Are the external {} really necessary? I can't see any difference here.

Yes; they are what enable the lazy evaluation feature of options.

[dliessi (Davide Liessi)]

add external {}

[dliessi (Davide Liessi)]

Replying to ryandesign@…:

Replying to davide.liessi@…:

Are the external {} really necessary? I can't see any difference here.

Yes; they are what enable the lazy evaluation feature of options.

OK, I added them.

Do you think that this can be committed? I think that it wouldn't affect existing ports.

[mojca (Mojca Miklavec)]

Cc Me!

[juanrgar (Juan R. García Blanco)]

Cc Me!

[raimue (Rainer Müller)]

Cc Me!

[raimue (Rainer Müller)]

Committed in r115223.

[dliessi (Davide Liessi)]

Please revert r115223.

• It turns out that the external {} break , e.g., port info: instead of the name of the port I get ${github.project}.
• Even without the external {}, the subport defined in the Portfile in my local development repository is not recognized, and the old version present in MacPorts' main repository is seen instead.

On my machine the patch attachment:github-1.0.tcl.2.diff​ works exactly as intended: unless there are any objections, please commit it.

[dliessi (Davide Liessi)]

I'm sorry for the inconvenience caused by attachment:github-1.0.tcl.4.diff​ (and also the one that would have been caused by attachment:github-1.0.tcl.3.diff​).

I did try the patches, but in a local development repository and not in MacPorts' main repository, and the behaviour was different. In particular, port info was not broken.

I tried attachment:github-1.0.tcl.2.diff​ changing the PortGroup file in /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group, so I'm fairly confident that it works as intended.

[raimue (Rainer Müller)]

Reverted in r115231.

[ryandesign (Ryan Carsten Schmidt)]

r122343

[neverpanic (Clemens Lang)]

In fbfa973b2522436a5565f07bc1130c43a86ca033/macports-ports:

bitbucket portgroup: Fix subport behavior

The same problem that affected the github portgroup also exists in the
bitbucket portgroup. Fix it with a siliar patch.

See: #40831
Closes: #55467

[catap (Kirill A. Korinsky)]

In 7c78e351d6ba6010a127c046ffa0736b8b4e125a/macports-ports (master):

portgroups: respect subport name, when it matches project name

Sometime subport name is matched project name on bitbucket, github,
gitlab, etc. Let stop to overwrite name for this case.

See: #40831
See: #55467