Opened 6 years ago

Closed 6 years ago

#58290 closed enhancement (wontfix)

port lint should check sub-ports

Reported by: reneeotten (Renee Otten) Owned by:
Priority: Normal Milestone:
Component: base Version:
Keywords: Cc:
Port:

Description

At the moment, when doing a port lint <portname> it does not check the possible sub-ports (as far as I can tell). I am specifically interested in this for Python ports, where ideally it should check all the pyXY-<portname> sub-ports. I think it would be good to add this because it would catch missing pyXY dependencies that now slip through the cracks.

If this is deemed a good idea I am happy to take a look at it (and perhaps some other "port lint" related, open tickets at the same time). I am not sure though whether my current tcl knowledge is sufficient, so I'll probably need some guidance.

Change History (7)

comment:1 Changed 6 years ago by mf2k (Frank Schima)

I'm not understanding the need for this. You can easily check a sub-port with:

port lint py37-numpy

comment:2 Changed 6 years ago by mf2k (Frank Schima)

Keywords: lint removed

comment:3 in reply to:  1 Changed 6 years ago by reneeotten (Renee Otten)

Replying to mf2k:

I'm not understanding the need for this. You can easily check a sub-port with:

port lint py37-numpy

Yes, of course one could do that manually for all subports, but I doubt that many (new) people will do that several times for all sub-ports and/or variants... For example, in our PR instructions it says to "check your Portfile with port lint" and that is also what the CI tests do (admittedly, the CI tests will just fail later on when trying to install a sub-port with missing dependencies).

I think it would make port lint more user-friendly and at the same time increase the chances of catching errors; but if there would be consensus that this is unneeded, fine with me.

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

The problem is that port lint does two different kinds of checks:

  1. it reads the Portfile line by line and checks for certain syntactic and stylistic errors
  2. it checks the variables that MacPorts base has set after processing the Porfile and validates their values

Before subports existed, this distinction wasn't too important, but now that we have subports, it's a little confusing because the first check covers the entire Portfile while the second check only covers the specified subport.

I don't see anywhere in proc portlint::lint_main where it tells MacPorts to populate the variables for the specified subport, so I assume MacPorts base has already done that before calling portlint::lint_main. That makes it difficult to have port lint check the variables of more than just the specified subport.

comment:5 Changed 6 years ago by jmroot (Joshua Root)

Only the specified variants are checked as well, and only the pathways corresponding to the current OS, Xcode version, etc. I don't think that's a big problem. For subports at least it's not hard to say foo subportof:foo (and I don't think that this one action should behave differently by operating on more ports than were specified).

comment:6 Changed 6 years ago by reneeotten (Renee Otten)

thank you all for the comments and feel free to close this Ticket (I can do it as well, probably with "wontfix" as resolution)?

I was not aware of the subportof pseudo-portname and seem unable to find this in man port or the guide, am I looking in the wrong place? That's indeed useful and will do what I was looking for.

comment:7 Changed 6 years ago by reneeotten (Renee Otten)

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.