Add 'add' subcommand to port select

[gpanders]

I sent an email to the macports-dev list earlier today asking about this, but admittedly I got a little excited and just went ahead and implemented a prototype.

---

This can be used to create user-specific, adhoc select groups. The
syntax is

port select --add <group> <target> <name>:<link> [<name>:<link>...]

For example, consider clangd which is installed in the clang port.
clangd is installed to bin/clangd-mp-X (for some LLVM version X). If a
user wants to use this version as simply bin/clangd they can use

port select --add clangd bin/clangd clang-mp-13:bin/clangd-mp-13
port select --set clangd clang-mp-13

The user can install any number of alternatives, but at least one is
required.

[mascguy]

Would we also want corresponding command port select --delete, to remove an adhoc grop?

[ryandesign]

The CI runs failed and the logs have already expired so I don't know why.

an email to the macports-dev list earlier today

Here is the link: https://lists.macports.org/pipermail/macports-dev/2021-December/043957.html

In it, you mentioned the use case you showed above, creating a new select group for clangd since it could not be added to the normal clang select group per macports/macports-ports#10558. I'm concerned that allowing user-created select groups, which would put the selected symlinks somewhere in /opt/local, might cause issues in other ports, and that this would be difficult to diagnose since a standard MacPorts installation would not have those files. For example, currently no MacPorts port or select group installs /opt/local/bin/clangd. Imagine that some port in our collection searches for clangd at configure time, does not find it, and thus builds itself without clangd support. Now imagine you invent a clangd select group that installs an /opt/local/bin/clangd symlink. Then, when you build that port that could optionally use clangd, it finds clangd and uses it. In the best case, this works fine and is merely a violation of reproducible builds, but it could also cause a build failure if the optional clangd support in that other port contains bugs or code that doesn't build on macOS. If you file a bug with us about this, whoever receives the report may scratch their heads about why a clangd was found when no MacPorts port or select group installs it. Yes, opportunistic use of selected binaries is a problem we already have for all the existing select groups, but the point is that MacPorts developers know (or can find out) what select groups exist and plan to work around them in their ports. But when you ask for MacPorts users to be able to create their own groups on-the-fly, you're asking all MacPorts developers to accept the additional tech support burden of potentially any binary appearing in /opt/local/bin and derailing the build of their ports.

You also mentioned a second use case where the universal-ctags port installs a binary uctags and you want to make a select group so that it can be accessed as ctags. MacPorts renames the universal-ctags port's binary to avoid a conflict with the ctags port. All MacPorts ports that use the universal-ctags port's program know to use it as uctags while all ports that want to use the ctags port's program know to use it as ctags. If you change the rules so that uctags is now aliased as ctags, that could break the ports that want to use the ctags port's program. Why can't you use a shell alias (in your shell startup file) or manually-created symlink (e.g. in /usr/local/bin or $HOME/bin) to solve this problem? MacPorts base won't look in those places when it builds other ports so that would avoid most of the problems.