macports challenges

[Ruben Di Battista]

I wanted to provide my feedback w.r.t. this topic. 

I also contribute to other “package manager”, a bit more tailored to HPC (EasyBuild and Spack) and in my opinion, more than the actual advertisement, the real hindering factor for Macports is TCL. TCL is hard, at least compared to Ruby or Python. It has a soul that is more oriented towards scripting than programming, and it makes hard to dive into port development. 

Another aspect that in my opinion is lacking at Macports side is a deep documentation on Portfile development. For example I still don’t know how most of the PortGroups work and often my workflow is to identify a well known port that makes use of a specific PortGroup and replicate most of the behavior (or otherwise looking directly in the source of the PortGroup). If we compare with Spack package.py development docs or EasyBuild easyconfigs/easyblocks I think we can easily highlight a documentation debt. 

Another aspect I would like to highlight, and this is more personal maybe, is related to the communication interaction w/ the community. I find myself the mailing list sort of obsolete. Moreover, very often, there’s an overlap between the subjects in macports-users and the ones of macports-dev. Again, both Spack and EB communities are on Slack.  I’m not here endorsing a proprietary, non-free, platform (there are FOSS alternatives), but I find the “ChatOps” movement and communication strategy very effective to promote community interaction.

Just my 2¢ :)

          _   
-.     .´  |∞∞∞∞
  ',  ;    |∞∞∞∞∞∞
    ˜˜     |∞∞∞∞∞∞∞∞∞ RdB
    ,.,    |∞∞∞∞∞∞
  .'   '.  |∞∞∞∞
-'       `’

https://rdb.is

On 6 dicembre 2018 a 15:28:37, Jonathan Stickel (jjstickel at gmail.com) scritto:

I'm glad to see some constructive discussion. After I sent the email, I  
was quite worried of the negative tone, and that it might be perceived  
as trolling. Sorry if that is true; it was not my attention.  

On 12/6/18 01:13, Nils Breunese wrote:  
> Rainer Müller wrote:  
>  
>> Somehow the Homebrew community managed to get their ubiquitous marketing  
>> on almost every software project website. Compare this with the MacPorts  
>> website, which has not seen any redesign in more than 10 years...  
>>  
>> Although a good package management system should not need to advertise  
>> itself, as every software would be available without users being told  
>> where to look – the package manager should be their first choice.  
>  
> But you need to know about this package manager first then. And be  
> convinced into installing and using it. I found out about the existence  
> of package managers on Mac (I guess it was Fink for me at the time)  
> through installation instructions for some tool I wanted to install.  
>  
> When I started to maintain some packages for MacPorts I also made an  
> effort to do pull requests for the install docs to add instructions for  
> installing via MacPorts (for instance [0]). I think this is very  
> important PR for a package manager, apart from its own website.  
>  
> For instance, yesterday I wanted to try out Hugo. It’s available in  
> MacPorts, but the Hugo site only mentions Homebrew, binary download and  
> building from source as installation options [1]. I think it might pay  
> off if maintainers would pay more attention to this.  
>  

This is a great idea. When a new port is added, the maintainer (or  
requester) should be encouraged to facilitate docs/instructions/notes  
upstream that the software is available in macports. (I wouldn't make it  
a requirement -- requirements can be perceived as draconian and keep  
people away.) Is there a place in the guide or wiki to say this? Maybe  
chapter 4 of the guide, "Portfile Development"?  

I'll work on retroactively doing this for the ports for which I am  
maintainer.  


> Nils.  
>  
> [0]  
> https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#getting-started-macports-cli-installation  
> [1] https://gohugo.io/getting-started/installing#pick-your-method  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20181206/f846049c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP using AMPGpg
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20181206/f846049c/attachment.sig>