Re: port "cask" -- installing prebuilt binaries

[Mark Anderson]

I like the idea of a separate thing like cask, (if only in labeling) but we
don't always need it/shouldn't use it exclusively.

Like maybe for restrictive non-free stuff like Chrome a different mode
makes sense, but with iTerm, I'm just trying to allow install on <10.15 and
knowing the iTerm guy, pretty soon, less than 11.0

Maybe just:
---> iTerm2 is only available via binary on this system, source is
available on 10.15+

---> Chrome is only available via binary

I'm not suggesting a Chrome port BTW, it's just the first thing I thought
of since I'm using it right this second to send this.

—Mark
___
Mark E. Anderson 
MacPorts Trac WikiPage 
GitHub Profile 



On Sun, Dec 13, 2020 at 4:42 PM Mark Anderson  wrote:

> I like the idea of a separate thing like cask, (if only in labeling) but
> we don't always need it/shouldn't use it exclusively.
>
> Like maybe for restrictive non-free stuff like Chrome a different mode
> makes sense, but with iTerm, I'm just trying to allow install on <10.15 and
> knowing the iTerm guy, pretty soon, less than 11.0
>
> Maybe just:
> ---> iTerm2 is only available via binary on this system, source is
> available on 10.15+
>
> ---> Chrome is only available via binary
>
> I'm not suggesting a Chrome port BTW, it's just the first thing I thought
> of since I'm using it right this second to send this.
>
>
> Thanks,
> —Mark
> ___
> Mark E. Anderson 
> Find me on LinkedIn 
>
>
> On Sun, Dec 13, 2020 at 4:30 PM Nils Breunese  wrote:
>
>> Ken Cunningham  wrote:
>>
>> So, I'm looking to install iTerm2 for old systems from binary as building
>> is becoming increasingly impossible - have we come to a consensus on any of
>> this?
>>
>> —Mark
>> ___
>> Mark E. Anderson > >
>> MacPorts Trac WikiPage 
>> GitHub Profile 
>>
>>
>>
>>
>>
>> I continue to believe that in general trying to shoehorn "cask" binary
>> installs as some variant of a port that is generally meant to build from
>> source is a recipe for nothing but endless trouble. Homebrew has a
>> completely different subsystem for cask installs that makes it really clear
>> what you are getting, and this is very desirable, I agree.
>>
>>
>> IMHO binary-only install port should have some clearly recognizable port
>> name that does not cause confusion about what it is, and does not obscure
>> or trample a port's existing variants (which a "prebuilt" or other similar
>> variant name would do, if there were other variants). We have port name
>> distinctions for a great many ports in MacPorts now (the perl, python, php,
>> etc, etc, etc port families, for example). Having a naming family for
>> binary-only ports is No Big Deal.
>>
>>
>> Chris has suggested a category inclusion, which is pure and uses macports
>> unique functionality, but IMHO is unrecognizable for 99.% of users who
>> would never notice that a given port is added to a certain category or
>> subcategory.
>>
>>
>> But we should resolve this, as many people want it, whatever is decided
>> by the managers, who so far have expressed no opinion, ergo it is
>> unresolved.
>>
>>
>> Why is having binary ports without a special indicator a problem?
>> MacPorts has already has ports that use upstream binaries, mostly for ports
>> that are either impossible to build from source (Google Cloud SDK source is
>> not available AFAIK for instance), or very hard/time-consuming (OpenJDK for
>> instance) to build. I maintain a couple of ports like these and they don’t
>> have a specific name or variant or anything indicating that they use
>> upstream binaries and I don’t see a problem with that really. If someone
>> would ever decide it’s a good idea to switch to building OpenJDK from
>> source via a Portfile, that could just be transparently done without any
>> users having to switch to a different port name or variant, and that seems
>> fine to me.
>>
>> It might even make sense for some ports (like iTerm2 perhaps?) to build
>> from source on macOS versions for which that is feasible, and use an
>> upstream binary on OS versions for which it isn’t.
>>
>> Nils.
>>
>

Re: port "cask" -- installing prebuilt binaries

[Nils Breunese]

Ken Cunningham  wrote:

>> So, I'm looking to install iTerm2 for old systems from binary as building
>> is becoming increasingly impossible - have we come to a consensus on any of
>> this?
>> 
>> —Mark
>> ___
>> Mark E. Anderson 
>> MacPorts Trac WikiPage 
>> GitHub Profile 
>> 
>> 
>> 
> 
> I continue to believe that in general trying to shoehorn "cask" binary 
> installs as some variant of a port that is generally meant to build from 
> source is a recipe for nothing but endless trouble. Homebrew has a completely 
> different subsystem for cask installs that makes it really clear what you are 
> getting, and this is very desirable, I agree.
> 
> 
> 
> IMHO binary-only install port should have some clearly recognizable port name 
> that does not cause confusion about what it is, and does not obscure or 
> trample a port's existing variants (which a "prebuilt" or other similar 
> variant name would do, if there were other variants). We have port name 
> distinctions for a great many ports in MacPorts now (the perl, python, php, 
> etc, etc, etc port families, for example). Having a naming family for 
> binary-only ports is No Big Deal.
> 
> 
> 
> Chris has suggested a category inclusion, which is pure and uses macports 
> unique functionality, but IMHO is unrecognizable for 99.% of users who 
> would never notice that a given port is added to a certain category or 
> subcategory.
> 
> 
> 
> But we should resolve this, as many people want it, whatever is decided by 
> the managers, who so far have expressed no opinion, ergo it is unresolved.
> 

Why is having binary ports without a special indicator a problem? MacPorts has 
already has ports that use upstream binaries, mostly for ports that are either 
impossible to build from source (Google Cloud SDK source is not available AFAIK 
for instance), or very hard/time-consuming (OpenJDK for instance) to build. I 
maintain a couple of ports like these and they don’t have a specific name or 
variant or anything indicating that they use upstream binaries and I don’t see 
a problem with that really. If someone would ever decide it’s a good idea to 
switch to building OpenJDK from source via a Portfile, that could just be 
transparently done without any users having to switch to a different port name 
or variant, and that seems fine to me.

It might even make sense for some ports (like iTerm2 perhaps?) to build from 
source on macOS versions for which that is feasible, and use an upstream binary 
on OS versions for which it isn’t.

Nils.

Re: port "cask" -- installing prebuilt binaries

[Mark Anderson]

So yeah - I think that a name and separate port is a good idea. I'm also on
board for the category for the 0.0001% of us that would use it.

maybe category: binary and binary-PortName like we do with like
py38-something


—Mark
___
Mark E. Anderson 
MacPorts Trac WikiPage 
GitHub Profile 



On Sun, Dec 13, 2020 at 3:15 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> So, I'm looking to install iTerm2 for old systems from binary as building
> is becoming increasingly impossible - have we come to a consensus on any of
> this?
>
> —Mark
> ___
> Mark E. Anderson  >
> MacPorts Trac WikiPage 
> GitHub Profile 
>
>
>
>
>
> I continue to believe that in general trying to shoehorn "cask" binary
> installs as some variant of a port that is generally meant to build from
> source is a recipe for nothing but endless trouble. Homebrew has a
> completely different subsystem for cask installs that makes it really clear
> what you are getting, and this is very desirable, I agree.
>
>
> IMHO binary-only install port should have some clearly recognizable port
> name that does not cause confusion about what it is, and does not obscure
> or trample a port's existing variants (which a "prebuilt" or other similar
> variant name would do, if there were other variants). We have port name
> distinctions for a great many ports in MacPorts now (the perl, python, php,
> etc, etc, etc port families, for example). Having a naming family for
> binary-only ports is No Big Deal.
>
>
> Chris has suggested a category inclusion, which is pure and uses macports
> unique functionality, but IMHO is unrecognizable for 99.% of users who
> would never notice that a given port is added to a certain category or
> subcategory.
>
>
> But we should resolve this, as many people want it, whatever is decided by
> the managers, who so far have expressed no opinion, ergo it is unresolved.
>
>
> K
>
>
>
>
>
>
>

Re: port "cask" -- installing prebuilt binaries

[Ken Cunningham]

So, I'm looking to install iTerm2 for old systems from binary as building
is becoming increasingly impossible - have we come to a consensus on any of
this?

—Mark
___
Mark E. Anderson https://lists.macports.org/mailman/listinfo/macports-dev>>
MacPorts Trac WikiPage >
GitHub Profile >





I continue to believe that in general trying to shoehorn "cask" binary 
installs as some variant of a port that is generally meant to build from 
source is a recipe for nothing but endless trouble. Homebrew has a 
completely different subsystem for cask installs that makes it really 
clear what you are getting, and this is very desirable, I agree.



IMHO binary-only install port should have some clearly recognizable port 
name that does not cause confusion about what it is, and does not 
obscure or trample a port's existing variants (which a "prebuilt" or 
other similar variant name would do, if there were other variants). We 
have port name distinctions for a great many ports in MacPorts now (the 
perl, python, php, etc, etc, etc port families, for example). Having a 
naming family for binary-only ports is No Big Deal.



Chris has suggested a category inclusion, which is pure and uses 
macports unique functionality, but IMHO is unrecognizable for 99.% 
of users who would never notice that a given port is added to a certain 
category or subcategory.



But we should resolve this, as many people want it, whatever is decided 
by the managers, who so far have expressed no opinion, ergo it is 
unresolved.



K

Re: port "cask" -- installing prebuilt binaries

[Mark Anderson]

So, I'm looking to install iTerm2 for old systems from binary as building
is becoming increasingly impossible - have we come to a consensus on any of
this?

—Mark
___
Mark E. Anderson 
MacPorts Trac WikiPage 
GitHub Profile 



On Thu, Sep 24, 2020 at 6:55 AM Lothar Haeger  wrote:

>
> Am 15.08.2020 um 10:37 schrieb Lothar Haeger :
>
> The variant name is: +prebuilt
>
>
> I like that name for its conciseness, lack of an underscore and correct
> tense. :-)
>
>
> So here's an example how this could look like in real life:
> https://github.com/macports/macports-ports/pull/8503
>
> Opinions?
>