GSoC Proposal: Rewrite key parts of MacPorts in Python

Ruben Di Battista rubendibattista at gmail.com
Tue Mar 31 21:26:27 UTC 2020


I have no experience to gave you any valuable help on this Alex, just wanted to drop some ideas I have in mind. 

I work in the frame of HPC computing and I’m a heavy user of spack (https://spack.readthedocs.io/en/latest/). It’s a package manager tailored for HPC that shares more than few features and design approach with Macports.
 
- It compiles for Unixes on different architectures (Including Power) and on Mac.
- has lots of optimized packages for specific architectures 
- Isolated spack environments and filesystem views

I would argue is a bit less stable for daily use as we do with Macports, but I find the packages very pleasant to write and the community is vibrant. So I would like to tell you to consider, maybe, to base your eventual work on that. Maybe making Macports packages compatible with their API or also using their infrastructure and strip most of the HPC-related features replacing them with the few, unique, feature Macports provides. Maybe discussing with them on the best approach to use their work in order to avoid to reinvent the wheel could be beneficial. I think the approach would be probably based on their spack environments/view (https://spack.readthedocs.io/en/latest/environments.html).

One of the proposed issues over there is to turn the actual spack “binary” into a library that other projects can leverage. Could it be feasible way to integrate a mature ecosystem with Macports? Maybe other people from the community could give it a look and express their opinion on that. 

Good luck! 

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

https://rdb.is

On 31 March 2020 at 23:15:02, Alex Ionkov (aionkov at gmail.com) wrote:

Dear MacPorts community, 

I submitted a proposal this year for rewriting parts of MacPorts in Python. The eventual goal is to rewrite all of MacPorts in Python to increase modularity and make integration of other APIs with MacPorts easier. 

I've attached my proposal. As for some edits that have already been recommended to me for more measurable goals, by each evaluation I would want to have rewritten an X amount of functions or functionality. 

What I would request from the community is advice on which functions would be the most valuable and useful and how to split them among the evaluation periods. Some recommendations that I have received already include getting information from the webapp to implement functionality that is not yet available and also rewriting functions such as fetch, dependency calculation, livecheck and install.

I'm currently working on integrating a small Python script which tells you the latest successful build of a port with the Tcl source as a proof of concept.

Thank you very much for your time,
Alex Ionkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200331/ad55da5c/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/20200331/ad55da5c/attachment.sig>


More information about the macports-dev mailing list