<html><head><style>body{font-family:Merriweather,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div  style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); margin: 0px; line-height: auto;">I wanted to provide my feedback w.r.t. this topic. </div><div  style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); margin: 0px; line-height: auto;"><br></div><div  style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); margin: 0px; line-height: auto;">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. </div><div  style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); margin: 0px; line-height: auto;"><br></div><div  style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); margin: 0px; line-height: auto;">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 <a href="https://spack.readthedocs.io/en/latest/tutorial_packaging.html">development docs</a> or EasyBuild <a href="https://easybuild.readthedocs.io/en/latest/Writing_easyconfig_files.html">easyconfigs</a>/<a href="https://easybuild.readthedocs.io/en/latest/Implementing-easyblocks.html#implementing-easyblocks">easyblocks</a> I think we can easily highlight a documentation debt. </div><div  style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); margin: 0px; line-height: auto;"><br></div><div  style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); margin: 0px; line-height: auto;">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.</div><div  style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); margin: 0px; line-height: auto;"><br></div><div  style="font-family:Merriweather,Arial;font-size:13px; color: rgba(51,51,51,1.0); margin: 0px; line-height: auto;">Just my 2¢ :)</div> <br> <div  class="gmail_signature">

        <title></title>

        <pre>          _   

-.     .´  |∞∞∞∞

  ',  ;    |∞∞∞∞∞∞

    ˜˜     |∞∞∞∞∞∞∞∞∞ RdB

    ,.,    |∞∞∞∞∞∞

  .'   '.  |∞∞∞∞

-'       `’

https://rdb.is

</pre>

</div> <br><p class="airmail_on">On 6 dicembre 2018 a 15:28:37, Jonathan Stickel (<a href="mailto:jjstickel@gmail.com">jjstickel@gmail.com</a>) scritto:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>I'm glad to see some constructive discussion. After I sent the email, I  

<br>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.

<br>

<br>On 12/6/18 01:13, Nils Breunese wrote:

<br>> Rainer Müller wrote:

<br>>  

<br>>> Somehow the Homebrew community managed to get their ubiquitous marketing

<br>>> on almost every software project website. Compare this with the MacPorts

>> website, which has not seen any redesign in more than 10 years...

<br>>>

<br>>> Although a good package management system should not need to advertise

<br>>> itself, as every software would be available without users being told

>> where to look – the package manager should be their first choice.

<br>>  

<br>> But you need to know about this package manager first then. And be  

<br>> convinced into installing and using it. I found out about the existence  

<br>> 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.

<br>>  

<br>> When I started to maintain some packages for MacPorts I also made an  

<br>> effort to do pull requests for the install docs to add instructions for  

<br>> installing via MacPorts (for instance [0]). I think this is very  

> important PR for a package manager, apart from its own website.

<br>>  

<br>> For instance, yesterday I wanted to try out Hugo. It’s available in  

<br>> MacPorts, but the Hugo site only mentions Homebrew, binary download and  

<br>> building from source as installation options [1]. I think it might pay  

> off if maintainers would pay more attention to this.

<br>>  

<br>

<br>This is a great idea. When a new port is added, the maintainer (or  

<br>requester) should be encouraged to facilitate docs/instructions/notes  

<br>upstream that the software is available in macports. (I wouldn't make it  

<br>a requirement -- requirements can be perceived as draconian and keep  

<br>people away.) Is there a place in the guide or wiki to say this? Maybe  

chapter 4 of the guide, "Portfile Development"?

<br>

<br>I'll work on retroactively doing this for the ports for which I am  

maintainer.

<br>

<br>

<br>> Nils.

<br>>  

<br>> [0]  

<br>> https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#getting-started-macports-cli-installation

<br>> [1] https://gohugo.io/getting-started/installing#pick-your-method

<br></div></div></span></blockquote></body></html>