Opened 10 years ago

Closed 10 years ago

Last modified 2 years ago

#40831 closed defect (fixed)

PortGroup github 1.0 shouldn't set name in subport

Reported by: dliessi (Davide Liessi) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.2.99
Keywords: github PortGroup Cc: ryandesign (Ryan Carsten Schmidt), mojca (Mojca Miklavec), juanrgar (Juan R. García Blanco), raimue (Rainer Müller)
Port: github

Description

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.)

Attachments (4)

github-1.0.tcl.diff (513 bytes) - added by dliessi (Davide Liessi) 10 years ago.
github-1.0.tcl.2.diff (584 bytes) - added by dliessi (Davide Liessi) 10 years ago.
github-1.0.tcl.3.diff (467 bytes) - added by dliessi (Davide Liessi) 10 years ago.
use default name
github-1.0.tcl.4.diff (469 bytes) - added by dliessi (Davide Liessi) 10 years ago.
add external {}

Download all attachments as: .zip

Change History (24)

comment:1 Changed 10 years ago by 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.

Changed 10 years ago by dliessi (Davide Liessi)

Attachment: github-1.0.tcl.diff added

comment:2 Changed 10 years ago by 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​.

Last edited 10 years ago by dliessi (Davide Liessi) (previous) (diff)

comment:3 Changed 10 years ago by dliessi (Davide Liessi)

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

Changed 10 years ago by dliessi (Davide Liessi)

Attachment: github-1.0.tcl.2.diff added

comment:4 Changed 10 years ago by 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?

comment:5 Changed 10 years ago by 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?

comment:6 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Why does this need to be any more complicated than changing

name                ${github.project}

to

default name        {${github.project}}

?

comment:7 in reply to:  6 ; Changed 10 years ago by 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.

Changed 10 years ago by dliessi (Davide Liessi)

Attachment: github-1.0.tcl.3.diff added

use default name

comment:8 Changed 10 years ago by dliessi (Davide Liessi)

I upgraded the patch according to Ryan's suggestion.

comment:9 in reply to:  7 ; Changed 10 years ago by 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.

Changed 10 years ago by dliessi (Davide Liessi)

Attachment: github-1.0.tcl.4.diff added

add external {}

comment:10 in reply to:  9 Changed 10 years ago by 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.

comment:11 Changed 10 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:12 Changed 10 years ago by juanrgar (Juan R. García Blanco)

Cc: juanrgar@… added

Cc Me!

comment:13 Changed 10 years ago by raimue (Rainer Müller)

Cc: raimue@… added

Cc Me!

comment:14 Changed 10 years ago by raimue (Rainer Müller)

Resolution: fixed
Status: newclosed

Committed in r115223.

comment:15 Changed 10 years ago by dliessi (Davide Liessi)

Resolution: fixed
Status: closedreopened

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.

comment:16 Changed 10 years ago by 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.

comment:17 Changed 10 years ago by raimue (Rainer Müller)

Reverted in r115231.

comment:18 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: reopenedclosed

comment:19 Changed 6 years ago by 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

comment:20 Changed 2 years ago by 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

Note: See TracTickets for help on using tickets.