Allow customizing applications_dir on a per-port basis

[esbugz]

I don't like to have a single folder dump and usually sort my apps in categories (e.g., video, office, etc.)

Homebrew allows you to pass a custom path argument for each cask (binary app) so that the native Mac app can be placed in an arbitrary folder within /Applications However, as far as I understand, MacPorts only allows a global applications_dir configuration variable, not a per-port installation flag

It would be great if MacPorts also allowed a per-port target folder for native Mac app bundles

[ryandesign (Ryan Carsten Schmidt)]

It's a nice idea, but I don't see how it would be possible in the general case. The paths where a port installs its files are baked into the pre-compiled archives we distribute. If you change the prefix or applications_dir or certain other variables in macports.conf (which applies to all ports), then you are no longer able to receive our pre-compiled archives, which is a significant drawback of deviating from our defaults. The same would apply to any hypothetical ability to customize it on a per-port basis, unless MacPorts were rearchitected. At minimum, it would require some ability of MacPorts to move selected items from wherever they are in the pre-compiled archive to wherever you wanted them to be, however paths to those items might be embedded in other files installed by the port, so those references would need to be found and updated as well, which may not be possible if the reference is within a binary file. References to the items you wanted to move might even be contained within other ports; how could we deal with that situation?

[kencu (Ken)]

You can alias the apps whever you want.

I use homebrew’s casks sometimes, but find it very confusing to not know which apps are bring managed by brew and which I installed, without checking every time. I label them, but the labels disappear on updates.

So I find having all the MacPorts apps in one folder is much much easier to keep that straight.

[esbugz]

Replying to kencu:

You can alias the apps whever you want.

That's what I did before I learned about this command

I use homebrew’s casks sometimes, but find it very confusing to not know which apps are bring managed by brew and which I installed, without checking every time.

So I find having all the MacPorts apps in one folder is much much easier to keep that straight.

That's fine, I find the opposite to be the case. I don't really need that information all that often, and if you do,

I label them, but the labels disappear on updates.

that's exactly what aliases are for — they convey that labeling information and only that. But you can't alias your way out of lacking app size and not knowing that your picture viewers apps occupy 2G because you've installed a bunch of them from various sources to compare and forgot to delete

[kencu (Ken)]

no, aliases don't "convey that labelling information and only that." That would be pretty useless.

They function as movable references to an application that you can put anywhere you want. Which is exactly what you are asking for.

But they don't require re-engineering MacPorts in a basically impossible and (IMHO) inferior way.

Lacking app size in an alias is a pretty trivial complaint, wouldn't you agree? :>

[esbugz]

Replying to ryandesign:

It's a nice idea, but I don't see how it would be possible in the general case. The paths where a port installs its files are baked into the pre-compiled archives we distribute. If you change the prefix or applications_dir or certain other variables in macports.conf (which applies to all ports),

I'm not talking about a general case and prefix, but mostly about GUI apps that should work from any folder (e.g., ​https://ports.macports.org/port/alacritty/) (though I'm in general curious why the build have evolved in such a way as to be so sensitive to absolute paths instead of relying on some env var or other method of relative system overrides, it's not something I plan to as MacPorts to solve)

then you are no longer able to receive our pre-compiled archives which is a significant drawback of deviating from our defaults.

Absolutely, breaking this would be a disaster, it's too much of a waste having to rebuild the world instead of downloading a prebuilt binary that was grown in an organic app farm ;).

may not be possible if the reference is within a binary file. References to the items you wanted to move might even be contained within other ports; how could we deal with that situation?

a) Would a symlink to the new app's location help? b) if not, then these apps would simply not be good candidates for relocation

[esbugz]

Replying to kencu:

no, aliases don't "convey that labelling information and only that." That would be pretty useless.

Why would they be useless if you complained that your labels were lost on app updates??? Links persist on app updates, that's useful. I used them exactly for this + for the labeling info itself: e.g., I'd change the app names from various Kitty and Puppy to File Manager Kitty and File Manager Puppy (and you could add (Macports) at the end if you need that label), and then the apps were easier to find in Alfred (especially for rarely used apps the names of which you could forget). That's the second use of the useless labels

They function as movable references to an application that you can put anywhere you want. Which is exactly what you are asking for.

Nope, not sure why you'd insist in your misinterpretation of what I'm asking for when I've explicitly explained that the alias is not it.

But they don't require re-engineering MacPorts in a basically impossible and (IMHO) inferior way.

Why is that impossible???

Lacking app size in an alias is a pretty trivial complaint, wouldn't you agree? :>

Compared to the made up impossibility, yep; otherwise, not really, why would I agree with trivializing one of the main driving factors behind the request a copy of this Homebrew's flag?

[kencu (Ken)]

you’re arguing hard against a perfectly-reasonable alias, yet just above you suggest a symlink as a solution…

the problem with forum posts is I can never tell if I’m debating a 10 year old…

[esbugz]

Replying to kencu:

you’re arguing hard against a perfectly-reasonable alias, yet just above you suggest a symlink as a solution…

a) it's not perfectly reasonable b) the symlinks is a proposed solution to a completely different issue

the problem with forum posts is I can never tell if I’m debating a 10 year old…

No, the problem is with your inability to understand and debate on the merits and resorting to these childish insults