Re: What's our audience - and how do we serve them best

[Bjarne D Mathiesen]

Ryan Schmidt wrote:
> On Apr 5, 2021, at 17:16, Bjarne D Mathiesen wrote:
>>
>> 1) what's our audience :
>>   ? newbies
>>   ? experienced
>>   ? nerds
>>   ? linux refugees
>>   each of these needs different kinds of handholding
>>
>> There's also a tendency to just abandon problems and wait for upstream
>> to fix them instead of finding (temporary) workarounds. Try looking for
>> "php80-imagick" in the threads.
> 
> The php imagick module is not compatible with php 8 or later. It is not our 
> job to make it so. Other than MacPorts base and supporting software, we do 
> not develop the software. We provide software that has been developed by 
> others and what the other developers choose to support or not is out of our 
> control.
> 
> Anyone is welcome to contribute e.g. to the upstream php imagick project to 
> make it php 8+ compatible. When that happens, we'll update to the new version 
> of MacPorts.

I fully understand that macports as such doesn't have the job of fixing
this situation upstream - and that's also not what I'm asking for /
proposing. I'm proposing something like when a port is deprecated so one
gets a note about the situation.

We are back to who the audience is :

If it's "nerds" -or- "linux refugees" all is good and well - they are
able to find the fix/workaround on their own (as I did).

But if we want to cater to newbies, we'll (IMHO) have to provide some
way to tell them :
- why isn't php80-imagick available
- what's the (possible) workaround

And php80-imagick is only used as an example here.

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: What's our audience - and how do we serve them best

[Ryan Schmidt]

On Apr 5, 2021, at 17:16, Bjarne D Mathiesen wrote:

> As I see it, we've got several problems/issues :
> 
> 1) what's our audience :
>   ? newbies
>   ? experienced
>   ? nerds
>   ? linux refugees
>   each of these needs different kinds of handholding
> 
> 2) how does one use macports in daily life ?
>   we've got a section :
>   https://trac.macports.org/wiki/howto
>   that we collectively ought try to promote better & bring up-to-date
>   & yes - I'm guilty here as the sections I've authored haven't been
>   kept updated :-( In my defence, I didn't experience much ethusiasm /
>   support for my efforts, so I more-or-less gave up.
>   There was/is a lot of negative put downs :
>   - "that's not recommended"
>   - "we don't do it that way"
>   instead of saying : "that's interesting !? why does he find it
>   necessary doing it that way ?!? could we incorporate his ideas &
>   improve upon them ?!?"
>   and generally no feedback at all.
>   I've just taken a look at some of the HowTo section for setting up a
>   MAMP - and it !really! needs improvement.

"We" includes you. If you have scripts you use that automate things that aren't 
in MacPorts and you think it should be in MacPorts, don't expect others to 
notice this; you may need to be the one to contribute whatever changes to 
MacPorts you think are needed. Same with documentation. Everyone just works on 
what they're interested in.


> 3) https://ports.macports.org/
>   is almost useless. If one searches for eg php, the newest version is
>   the third last from the bottom. All the other results are useless.

I'm sorry to hear you find it useless. I find it very helpful and use it daily. 
It provides a canonical URL for each port that can be given to others. The page 
tells you about the port. It tells you whether the most recent build on each 
platform succeeded or failed and provides access to recent build logs.

Certainly there is room for improvement. There is an issue tracker where 
several improvement suggestions have already been filed. The search result 
issue you mentioned is filed there. Many of the issues have already been 
implemented in a new version of that site that has not yet been deployed.


> 4) Public Relations
>   As has been stated elsewhere, almost nobody knows about macports.
>   Everybody references brew. I've just read a book on how to work with
>   Terminal :
>   https://www.apress.com/gp/book/9781484261705
>   and the go-to package manager is brew. Some of the stuff mentioned
>   installed with brew isn't present in macports, but those are minor
>   issues.
>   A course of action ought to be, that when one of us sees brew
>   referenced as !the! way to install something, then to take contact
>   and get the site to reference macports too.

Of course. People are welcomed and encouraged to disseminate information about 
MacPorts wherever it is needed.


> 
> There's also a tendency to just abandon problems and wait for upstream
> to fix them instead of finding (temporary) workarounds. Try looking for
> "php80-imagick" in the threads.

The php imagick module is not compatible with php 8 or later. It is not our job 
to make it so. Other than MacPorts base and supporting software, we do not 
develop the software. We provide software that has been developed by others and 
what the other developers choose to support or not is out of our control.

Anyone is welcome to contribute e.g. to the upstream php imagick project to 
make it php 8+ compatible. When that happens, we'll update to the new version 
of MacPorts.


> What I really, really, really like about macports is the option for
> editing a port file to fix an issue before upstream handles it - eg I've
> just had problems w/ youtube-dl not being the latest version, so I just
> edited the portfile.

youtube-dl *is* at the latest version; I updated it yesterday.

Re: map download link to distname

[Ryan Schmidt]

On Apr 5, 2021, at 16:33, Jonathan Stickel wrote:

> On 4/5/21 14:17, Ryan Schmidt wrote:
>> On Apr 5, 2021, at 14:43, Jonathan Stickel wrote:
>>> I'm working on updating the graphviz portfile.
>> Huh, I thought an update had already been submitted months ago.
> 
> No, as per discussion on the ticket:
> 
> https://trac.macports.org/ticket/62165
> 
> (I see you made more comments there, but providing the URL in case others are 
> interested)
> 
>>> The new download link is:
>>> 
>>> https://gitlab.com/graphviz/graphviz/-/package_files/8183714/download
>>> 
>>> I can get Macports to download it by using:
>>> 
>>> master_sites  https://gitlab.com/${name}/${name}/-/package_files/8183714
>>> distfiles download
>>> 
>>> But the download source file is named "download". How do I rename it to the 
>>> proper source file name "graphviz-2.47.0.tar.gz"? Forgive me if it is 
>>> obvious, but I couldn't find this information in the documentation or an 
>>> example in another Portfile.
>> https://trac.macports.org/wiki/PortfileRecipes#fetchwithgetparams
>> However, I would expect that using the gitlab portgroup would set up the 
>> correct download URLs for you automatically. If it does not, improve the 
>> gitlab portgroup since this need is not unique to the graphviz port.
> 
> From what I can tell, Graphviz (upstream) is not releasing their "preferred" 
> source package in a gitlab-typical way. Since the homepage is also different, 
> I was not going to use the gitlab portgroup.
> 
> I have previously observed that the github portgroup does rename the download 
> file from a differently named download link (e.g., `v1.0.tar.gz` to 
> `projectname-1.0.tar.gz`). I looked at the github portgroup source code and 
> could not figure out how it does it. That is why I am asking on the list for 
> help.

Projects hosted at gitlab should use the gitlab portgroup, just as projects 
hosted at github should use the github portgroup. It abstracts the knowledge of 
how to download files from those services, as well default homepages and 
livecheck settings, away into a single file that can be included by multiple 
ports. If the service ever changes how it works, we only have to fix it in one 
place.

Github and gitlab are different services that work in different ways, hence the 
separate portgroups.

The github portgroup does not rename downloaded files. Rather, it makes use of 
a feature of the github service that allows you to request an 
automatically-generated tarball of any filename, as long as you've specified 
the right tag in the URL. I don't know if the gitlab service has the same 
feature but it's not relevant here since the developers of graphviz have told 
us not to use the automatically-generated tarballs.

Instead they've told us to use their "portable source" which I presume is what 
I usually call a manually-generated tarball. The github service provides a 
means for developers to attach files to tagged releases, and the github 
portgroup provides a means of downloading such a file by specifying 
"github.tarball_from releases". (In retrospect the variable name "tarball_from" 
was probably not great since files are not necessarily tarballs; 
"download_from" or "download_type" might have been a better choice.) The gitlab 
service appears to offer a similar feature but the gitlab portgroup does not 
appear to offer a way to request such a download and should be enhanced to 
offer it.

Regarding the specific download link you mentioned, 
https://gitlab.com/graphviz/graphviz/-/package_files/8183714/download, I see 
that link on the graphviz web site at http://www.graphviz.org/download/source/ 
but I don't know where they got it. I can't find that link within their gitlab 
site. I don't know whether that is what in github parlance would be called a 
release download or whether it is yet another different type of download which 
is specific to gitlab for which there is not an equivalent within github.

Note that that link is for the .tar.gz source whereas we would want to use the 
.tar.xz source because it is smaller.

For now the way to do it would be:

name graphviz
version 2.47.0
set package_id 8183717
revision 0
checksums ...
use_xz yes
master_sites 
https://gitlab.com/graphviz/graphviz/-/package_files/${package_id}/download?dummy=

What's our audience - and how do we serve them best

[Bjarne D Mathiesen]

As I see it, we've got several problems/issues :

1) what's our audience :
   ? newbies
   ? experienced
   ? nerds
   ? linux refugees
   each of these needs different kinds of handholding

2) how does one use macports in daily life ?
   we've got a section :
   https://trac.macports.org/wiki/howto
   that we collectively ought try to promote better & bring up-to-date
   & yes - I'm guilty here as the sections I've authored haven't been
   kept updated :-( In my defence, I didn't experience much ethusiasm /
   support for my efforts, so I more-or-less gave up.
   There was/is a lot of negative put downs :
   - "that's not recommended"
   - "we don't do it that way"
   instead of saying : "that's interesting !? why does he find it
   necessary doing it that way ?!? could we incorporate his ideas &
   improve upon them ?!?"
   and generally no feedback at all.
   I've just taken a look at some of the HowTo section for setting up a
   MAMP - and it !really! needs improvement.

3) https://ports.macports.org/
   is almost useless. If one searches for eg php, the newest version is
   the third last from the bottom. All the other results are useless.

4) Public Relations
   As has been stated elsewhere, almost nobody knows about macports.
   Everybody references brew. I've just read a book on how to work with
   Terminal :
   https://www.apress.com/gp/book/9781484261705
   and the go-to package manager is brew. Some of the stuff mentioned
   installed with brew isn't present in macports, but those are minor
   issues.
   A course of action ought to be, that when one of us sees brew
   referenced as !the! way to install something, then to take contact
   and get the site to reference macports too.

5) what does our audiences want to use macports for ?
   ? webserver
   ? mailserver
   ? ...
   Those of us with diverse experience in different domains ought to
   describe their experiences in HowTo articles.

Yes - I do know that DucDuckGo exists.
But if you are at newbie, you'll need some (a lot of) hand-holding.
Referencing relevant books and web-pages in our HowTo section ought to
be standard best practise. I'm well aware, that one can't cover all
situations, but that's where references are of value. I don't know how
many books - both dead tree versions and pdf/ebook - I've read
conver-to-cover before even starting on a project.

There's also a tendency to just abandon problems and wait for upstream
to fix them instead of finding (temporary) workarounds. Try looking for
"php80-imagick" in the threads.

What I really, really, really like about macports is the option for
editing a port file to fix an issue before upstream handles it - eg I've
just had problems w/ youtube-dl not being the latest version, so I just
edited the portfile.

I'm willing to cooperate on stuff.

I've been using macs for my servers since the early 2000s
I started with compiling and installing apache, php & mysql from source
based upon ServerLogistics in 2004 and haven't looked back since. The
1st packet manager I used was fink, but when macports entered the scene,
I found macports to be better and jumped over.

I can do articles on setting up a MAMP server both simple and advanced.
Postfix & dovecot w/ MySQL integration is another subject.

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: map download link to distname

[Jonathan Stickel]

On 4/5/21 14:17, Ryan Schmidt wrote:



On Apr 5, 2021, at 14:43, Jonathan Stickel wrote:


I'm working on updating the graphviz portfile.


Huh, I thought an update had already been submitted months ago.



No, as per discussion on the ticket:

https://trac.macports.org/ticket/62165

(I see you made more comments there, but providing the URL in case 
others are interested)





The new download link is:

https://gitlab.com/graphviz/graphviz/-/package_files/8183714/download

I can get Macports to download it by using:

master_sites  https://gitlab.com/${name}/${name}/-/package_files/8183714
distfiles download

But the download source file is named "download". How do I rename it to the proper source 
file name "graphviz-2.47.0.tar.gz"? Forgive me if it is obvious, but I couldn't find this 
information in the documentation or an example in another Portfile.


https://trac.macports.org/wiki/PortfileRecipes#fetchwithgetparams

However, I would expect that using the gitlab portgroup would set up the 
correct download URLs for you automatically. If it does not, improve the gitlab 
portgroup since this need is not unique to the graphviz port.



From what I can tell, Graphviz (upstream) is not releasing their 
"preferred" source package in a gitlab-typical way. Since the homepage 
is also different, I was not going to use the gitlab portgroup.


I have previously observed that the github portgroup does rename the 
download file from a differently named download link (e.g., 
`v1.0.tar.gz` to `projectname-1.0.tar.gz`). I looked at the github 
portgroup source code and could not figure out how it does it. That is 
why I am asking on the list for help.


Thanks,
Jonathan

Re: macports-dev Digest, Vol 176, Issue 7

[Karl-Michael Schindler]

> Am 05.04.2021 um 22:17 schrieb macports-dev-requ...@lists.macports.org:
> 
> Date: Mon, 5 Apr 2021 20:51:23 +0200
> From: Nils Breunese 
> To: MacPorts Developers 
> Subject: Re: Desolate Condition
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
> 
> A more scalable solution would be for port maintainers to check the upstream 
> docs for the ports they maintain and contribute a snippet on how to install 
> the software via MacPorts if not already present. Usually all this takes is a 
> simple merge request. I think this is a great idea and I?ve been doing this 
> for my ports.
> 
> Examples from the Spring Boot documentation: 
> https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html#getting-started-macports-cli-installation
> 
> People will even start copying these MacPorts installation instructions into 
> blog posts and educational materials.
> 
> Examples of ?sudo port install kotlin?: 
> https://www.google.com/search?q=%22sudo+port+install+kotlin%22
> 
> Apparently it was even copied into an O?Reilly book: 
> https://www.oreilly.com/library/view/kotlin-programming-by/9781788474542/86027be9-71a7-4afc-8354-51fceeb741d9.xhtml
> 
> Nils.

Good point. I’ll check the MacPorts docs about creating packages and hope to 
extend the docs correspondingly.

Michael.

Re: Misconceptions about binaries (was: Re: Desolate Condition)

[Ryan Schmidt]

On Apr 3, 2021, at 19:21, Wowfunhappy wrote:
> 
> I know it's just one data point, but I thought the replies I got on this 
> Hacker News comment today were interesting. I can understand why he/she got 
> confused, and I wonder if there's anything MacPorts could do to make it 
> clearer. https://news.ycombinator.com/item?id=26678498

Thank you for trying to tackle the issue. I'm also reminded of:

https://xkcd.com/386/

Re: Desolate Condition

[Ryan Schmidt]

On Apr 5, 2021, at 13:04, Karl-Michael Schindler wrote:

> 2) Put the command 'port install PACKAFE_NAME' to a prominent position.

https://github.com/macports/macports-webapp/issues/144

Re: map download link to distname

[Ryan Schmidt]

On Apr 5, 2021, at 14:43, Jonathan Stickel wrote:

> I'm working on updating the graphviz portfile.

Huh, I thought an update had already been submitted months ago.


> The new download link is:
> 
> https://gitlab.com/graphviz/graphviz/-/package_files/8183714/download
> 
> I can get Macports to download it by using:
> 
> master_sites  https://gitlab.com/${name}/${name}/-/package_files/8183714
> distfiles download
> 
> But the download source file is named "download". How do I rename it to the 
> proper source file name "graphviz-2.47.0.tar.gz"? Forgive me if it is 
> obvious, but I couldn't find this information in the documentation or an 
> example in another Portfile.

https://trac.macports.org/wiki/PortfileRecipes#fetchwithgetparams

However, I would expect that using the gitlab portgroup would set up the 
correct download URLs for you automatically. If it does not, improve the gitlab 
portgroup since this need is not unique to the graphviz port.

map download link to distname

[Jonathan Stickel]

I'm working on updating the graphviz portfile. The new download link is:

https://gitlab.com/graphviz/graphviz/-/package_files/8183714/download

I can get Macports to download it by using:

master_sites  https://gitlab.com/${name}/${name}/-/package_files/8183714
distfiles download

But the download source file is named "download". How do I rename it to 
the proper source file name "graphviz-2.47.0.tar.gz"? Forgive me if it 
is obvious, but I couldn't find this information in the documentation or 
an example in another Portfile.


Thanks,
Jonathan

Re: Desolate Condition

[Nils Breunese]

Karl-Michael Schindler  wrote:

> This indicates the first problem: Brew is often better represented on 
> homepages of other software than MacPorts. The task to tackle is to find a 
> person or form a team going after this.

A more scalable solution would be for port maintainers to check the upstream 
docs for the ports they maintain and contribute a snippet on how to install the 
software via MacPorts if not already present. Usually all this takes is a 
simple merge request. I think this is a great idea and I’ve been doing this for 
my ports.

Examples from the Spring Boot documentation: 
https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html#getting-started-macports-cli-installation

People will even start copying these MacPorts installation instructions into 
blog posts and educational materials.

Examples of ’sudo port install kotlin’: 
https://www.google.com/search?q=%22sudo+port+install+kotlin%22

Apparently it was even copied into an O’Reilly book: 
https://www.oreilly.com/library/view/kotlin-programming-by/9781788474542/86027be9-71a7-4afc-8354-51fceeb741d9.xhtml

Nils.

Re: Desolate Condition

[Karl-Michael Schindler]

Am 05.04.2021 um 14:00 schrieb macports-dev-requ...@lists.macports.org:
> 
> To: MacPorts Developers 
> Subject: Re: Desolate Condition
> Message-ID: 
> 

Hi.

I think that the topic installing binaries or not points to a more general 
issue, namely public relations. MacPorts could improve a lot on this. For 
example by touting how many packages can be installed as binaries now. In 
addition, how many packages are offered by macports as well as things like what 
categories have the most installs or the most new packages or the most updated 
packages. I am fully aware that this sounds silly to some point. But in order 
to compete with homebrew, improving on technical aspects is not sufficient. 
Categories are a particular strength of MacPorts vs homebrew.

Asking friends, why they use brew instead of macports and their answer was, 
because it is easier to use. I said: 'What?' because what is the difference 
between brew install … and port install … ? But after looking a bit more into 
the details, the case of installing ImageMagick as a first time user turned out 
to be more revealing than expected:

So, from google your first hit is https://imagemagick.org. Going to 'Download' 
and 'Mac OS X Binary Release' gives you a page where you find 'brew install 
imagemagick' very prominently, but only a link for the homepage of MacPorts. 
This indicates the first problem: Brew is often better represented on homepages 
of other software than MacPorts. The task to tackle is to find a person or form 
a team going after this. The number of downloads would help a lot to focus on 
important packages. Maintainers could also be advised to check whether the 
upstream representation of MacPorts in the installation section of macOS 
compares to homebrew.

After being directed to the MacPorts homepage, it does not stop. The next step 
is searching on the pages for MacPorts for ImageMagick. This gets you to the 
page: "https://ports.macports.org/port/ImageMagick/summary“, which still does 
not tell you 'port install imagemagick'. One would guess that 'Build 
Information' gives you a hint and click on it, but no. Don’t get me wrong, for 
me as an experienced user of MacPorts this page is very helpful and tells me, 
what i want to know about a package, but for less experienced users it makes 
MacPorts look overly complicated. I suggest to make following changes to this 
page:

1) Place the 'View on Github' Button next to the name

2) Put the command 'port install PACKAFE_NAME' to a prominent position.

3) Change the sequence of the fields according to the importance for users, in 
particular first time users. 

My suggestion is this sequence.

1) Version
2) Variants
3) Platform
4) Categories
5) Depends on
6) Dependency of
7) Homepage
8) License
9) Maintainer

I also think that the concept of variants needs more explanations. Clicking on 
the variants does not give any indications about the implications of a variant. 
There is also no hint, which variant I should choose as a first time user. 
Hints regarding a default variant and hints about binary installation would be 
helpful. I am not sure about it, but it might be better to defer this 
information to another subpage, because of secondary importance.

I hope, i did not hurt or offend anyone. The work done by all the people for 
MacPorts is amazing and it is important to keep up the spirit. MacPorts has a 
rock solid foundation and only its appearance needs some corrections.

Regards - Michael.

Re: FAQ wording (was: Re: Desolate Condition)

[Jason Liu]

>
> What if the end of the first sentence was changed to: "ports will be
> installed for only the architecture you're currently running on."?
>

Besides being the most concisely worded, I also find this version to be the
most unambiguous. I think leaving the words "build/built" and "compile" out
of the sentence entirely would be for the best.

-- 
Jason Liu


On Mon, Apr 5, 2021 at 10:15 AM wowfunha...@gmail.com 
wrote:

> > It's a tricky thing to state both concisely and accurately because the
> > compilation may indeed happen on the user's computer after installation
> > is requested. Or it may not. The ambiguity of whether "be compiled" is a
> > verb in the passive voice ("the code is being compiled") or a
> > description of a state ("this is code compiled for x86_64") may reflect
> > the author's awareness of the undecidedness of which one will actually
> > happen.
> >
> > Improvements to the text's clarity are very welcome, of course.
> >
> > - Josh
>
> What if the end of the first sentence was changed to: "ports will be
> installed for only the architecture you're currently running on."?
> Basically mirroring the other change made on Saturday.
>
>
>

Re: FAQ wording (was: Re: Desolate Condition)

[wowfunha...@gmail.com]

> It's a tricky thing to state both concisely and accurately because the 
> compilation may indeed happen on the user's computer after installation 
> is requested. Or it may not. The ambiguity of whether "be compiled" is a 
> verb in the passive voice ("the code is being compiled") or a 
> description of a state ("this is code compiled for x86_64") may reflect 
> the author's awareness of the undecidedness of which one will actually 
> happen.
> 
> Improvements to the text's clarity are very welcome, of course.
> 
> - Josh

What if the end of the first sentence was changed to: "ports will be installed 
for only the architecture you're currently running on."? Basically mirroring 
the other change made on Saturday.

FAQ wording (was: Re: Desolate Condition)

[Joshua Root]

On 2021-4-4 11:20 , Kevin Reid wrote:
On Sat, Apr 3, 2021 at 5:22 PM wowfunha...@gmail.com 
 > wrote:


I know it's just one data point, but I thought the replies I got on
this Hacker News comment today were interesting. I can understand
why he/she got confused, and I wonder if there's anything MacPorts
could do to make it clearer.
https://news.ycombinator.com/item?id=26678498



As worded, the FAQ text "the ports you install will be compiled only for 
the architecture you're currently running on" implies (in the linguistic 
rather than logical sense) that the compilation happens after you 
request installation. The minimal patch would be to change the tense to 
"will *have been* compiled only for", but an even better rewording might 
be something like


"…the ports' installed binaries will have been compiled for your
computer's architecture…"


to avoid putting the user's computer in any active role in that sentence 
and to make it clear we're talking about the binaries and not the 
compilation process per se. Perhaps "will contain machine code for" 
would be even more rigorous, but it might be less familiar.


Of course, this sentence may not be the whole problem, but it's what I 
saw in that thread, it's likely /part/ of the problem, and it made a 
good example of the kind of sentence that can be read differently by a 
reader not already familiar with the subjet.


It's a tricky thing to state both concisely and accurately because the 
compilation may indeed happen on the user's computer after installation 
is requested. Or it may not. The ambiguity of whether "be compiled" is a 
verb in the passive voice ("the code is being compiled") or a 
description of a state ("this is code compiled for x86_64") may reflect 
the author's awareness of the undecidedness of which one will actually 
happen.


Improvements to the text's clarity are very welcome, of course.

- Josh