Google Summer of Code 2019

This is the MacPorts Project’s page for ​Google Summer of Code.

Information about the past years can be found at SummerOfCodeArchive.

Applications for GSoC

Students will be able to apply from 25 March until 9 April 18:00 UTC.

If you're interested in working with MacPorts for Google Summer of Code 2019, you don't have to wait until the application period for students starts. Introduce yourself on the macports-dev mailing list today or drop by in IRC by joining #macports on ​Freenode. See Ways to Contact Us for more information.

General info

For future reference, you may check the ​Google Summer of Code website. The ​GSoC Student Guide is also worth reading and explains what GSoC is about and how it works in detail. We suggest you take a few minutes and read this guide. See also ​So You Want to Be a Google Summer of Code Student? video.

For the official schedule and deadlines, consult the ​timeline.

Proposal Guidelines

Submit your proposal early: early submissions get more attention from developers for the simple fact that they have more time to dedicate to reading them. The more people see it, the more it'll get known.

Do not leave it all to the last minute: Make sure you send your application before the final rush. Also, note that the applications submitted very late will get the least attention from mentors, so you may get a low vote because of that.

Keep it simple: we don't need a 30-page essay on the project and on you. You just need to be concise and precise.

Know what you are talking about: the last thing we need is for students to submit ideas that cannot be accomplished realistically or ideas that aren't even remotely related to MacPorts or the project. If your idea is unusual, be sure to explain why you have chosen MacPorts as the best place for the project.

About Us

We are eager to support and mentor students who want to gain experience by working on the MacPorts Project. We have many ideas for potential internship subjects, yet we are open to anything that is both interesting and relevant to MacPorts. If you have an idea of your own, feel free to contact us to discuss it.

MacPorts is written in the Tcl scripting language with some low-level parts implemented in C. Most students that have previously applied and successfully completed Google Summer of Code with us did not know Tcl when they applied. Feel free to apply if you don't know Tcl yet, especially if you're willing to learn and already know several scripting languages such as Python, Ruby, PHP or Perl.

The best way to apply is to first make contact with us, either by sending a mail to the mailing list, to potential mentors listed below, or to IRC member on #macports on ​Freenode. See also Ways to Contact Us for in-depth information on how to reach us.

What we expect from students for their applications

• Write your own abstract and proposal, copying text from this idea page is not enough.
• Show us that you fully understand your task and know what you want to do over the summer.
• At best, include a short weekly roadmap covering how you would work on the task.
• Please use our application template.

What you should do before handing in an application

• Get familiar with the MacPorts Project resources. Especially check out the code and ​read the guide.
• If you plan on working for macports-base:
  • Read the ​Tcl Tutorial.
  • ​this could be a good introduction to the codebase.
• Subscribe to the mailing list ​macports-dev if you do not already read it. Don't be too shy to post.

Get in contact! Most important is to discuss your ideas with potential mentors via the MacPorts development list, or the IRC channel before applying.

Students

For the students and projects in the previous editions of GSoC with MacPorts, see SummerOfCodeArchive.

Projects

This is a list of some potential tasks that student GSoC members could undertake. These are just ideas, and while they express our current concerns, we are open to blue-sky projects related to MacPorts.

Please note that this list is absolutely not exclusive! If you have any idea about what you want to see improved in MacPorts, you are free to propose this as your own project. In any case, we recommend you talk to mentors before writing your application.

Ideas mainly fall into one of the following categories:

macports_base

You would be expected to extend and improve the functionality of the core of the package manager, mainly written in Tcl (and C). It's OK if you have no prior experience with Tcl though. See below for various ideas.

ports

With tens of thousands of available ports probably overlapping with your daily needs of the software. Portfiles are written in simple declarative Tcl, but you would probably spend more time figuring out how to (better) package the software which might be written in almost any programming language. A knowledge and passion of any language like C++, Perl, Ruby, Python, Rust, Go, Haskell, JavaScript, ... or technology like Qt, KDE, ... could greatly improve the support of certain software in our ecosystem.

infrastructure

Several independent projects to support development of MacPorts could be undertaken in any language of your choice (gravitating towards python & web), like writing a Django app in Python, improving frontend or backend of Buildbot continuous integration (JavaScript or Python), implementing a way to fire up virtual machines with macOS for continuous integration builds, ...

Ideas

Improving the Command Line Tool UX

The output of the MacPorts command-line tool is pretty bland. This definitely could be improved by modifying the Tcl source code of the command line tool. We could have more pretty stuff for better user experience: progress bars, emojis, bold text and colored text. The things that should be done entail (but are not exclusive to): detecting if the output channel is color-compatible (e.g. we can't color if we're outputting to a log file), figure out how to bold and color strings in Tcl (see ​https://misc.flogisoft.com/bash/tip_colors_and_formatting), also figure out the which parts of the text exactly we need to emphasise for good UX. See the ​ticket.

• Difficulty: Easy to Medium
• Languages: Tcl
• Potential mentors: ?
• Importance: High

Update Orphaned Ports

Several of the current MacPorts developers originally became interested in the project because they wanted to improve the software that MacPorts installs. Fixing and/or updating ports is an excellent introduction to the MacPorts systems (phases, variants, PortGroups, etc.). It forces you to read the documentation and examine commit histories. This does not have to be an entire GSOC project, but it could be used as part of the application process and/or a supplement to the main project. Most version increases in a port require only minor changes.

• Difficulty: Easy to Hard
• Languages: Tcl, the language of the port
• Potential mentors: mcalhoun
• Importance: Low

Managing and Fixing Qt Versions

Fix issues in open tickets for Qt 3, Qt 4, and Qt 5, in particular allowing for concurrent installation of the various Qt versions. There are around 50 outstanding tickets for the various Qt versions. Some involve patching and testing on multiple OSs. Some are probably invalid but need to be tested to determine validity. The end goal for this project is to allow for concurrent installation of the various Qt versions, and then verifying and resolving as many issues as possible that weren't resolved by the concurrent changes. Requires knowledge of Portfile programming (Tcl), Qt programming (primarily C++), and Qt makefile programming (QMake); other programming knowledge that would be useful include shell (e.g., bash) and C.

• Difficulty: Medium to Hard
• Languages: Tcl, C++, QMake
• Potential mentors: mcalhoun, michaelld
• Importance: Low

Make Blacklisting MacPorts Compilers Easier

Not all compilers work with all ports. MacPorts has a mechanism to blacklist compilers that do not meet the port's requirements. Currently, blacklisting a range of compilers is very easy (e.g. compiler.blacklist {clang < 500} ensures that the Clang compiler supports C++11). However, this only works for compilers provided by Xcode. Ports can also use compilers provided by MacPorts. It would be nice, for example, to be able to have something like compiler.blacklist {macports-clang < 6.0}.

• Difficulty: Easy to Medium
• Languages: Tcl
• Potential mentors: mcalhoun
• Importance: Low

Add Support for x86_64h Architecture

The system compilers have supported, at various times, x86_64, i386, ppc, and ppc64 as valid architectures. MacPorts has support for all four. Relatively recently, system compiler started supporting the x86_64h architecture, which is a lot like x86_64, except it allows compiler to take advantage of the Haswell microarchitecture. Adding the architecture support itself would be straightforward. However, it is not clear what, if any, performance improvement this could bring. Also, unlike other architectures in MacPorts, x86_64h and x86_64 libraries can be linked together.

• Difficulty: Medium
• Languages: Tcl
• Potential mentors: mcalhoun
• Importance: Low

Allow for Multiple Runs of Each Phase

There are times when it is convenient to run configure/build/destroot more than once. For example:

• cargo depends on the port cargo-stage1, whose only purpose is to help build cargo. Instead, one could run configure/build and use the resulting binary without installing another port.
• ​fluidsynth depends on a subproject, which has no use beyond aiding the build process. The subproject does not inherit the MacPorts settings. It would be nice to configure/build the subproject properly (from a MacPorts point of view).
• 75% of the muniversal PortGroup is to get multiple runs of the configure/build/destroot phases.

• Difficulty: Difficult
• Languages: Tcl
• Potential mentors: mcalhoun
• Importance: Low

Allow a Variant to More Elegantly Become “undefaulted”

A port can be installed with different ​variants. A variant is used if requested by a user or if the variant is declared default. If the default designation is removed, new installations will not use it, but it will continue to be used by the users who upgrade from a port version when it was still the default. It would be useful to have a way to perpetuate a previously default variant only if the user specifically requested it.

• Difficulty: Medium
• Languages: Tcl
• Potential mentors: mcalhoun
• Importance: High

Prevent port reclaim from Removing Build Dependencies

port reclaim attempts to keep only ports requested by the user or required by them. Currently, this means uninstalling ports used to build the port. There is ​interest in modifying this behavior.

• Difficulty: Medium
• Languages: Tcl
• Potential mentors: mcalhoun
• Importance: Medium

Give Portfile Better Access to CFLAGS, CXXFLAGS, etc.

Currently, the environmental variables CFLAGS, CXXFLAGS, and the like are set late in the process (arch flags added, -pipe added, etc.). Of course, there are ​good reasons for this. Unfortunately, this means that there is no Portfile access to these values. This causes some ugly workarounds such as duplication of code from the base or configure.cmd printenv and configure.post_args {>> Makefile.macports.inc}. Giving Portfile at least the option of accessing these values could help clean up Portfile code.

• Difficulty: Medium
• Languages: Tcl
• Potential mentors: mcalhoun
• Importance: Low

Simplify Compilers and MPI PortGroups with Recent Base Changes

Recently, significant changes were made in the base code concerning default compiler selection. As a result, the PortGroups that aid in user defined compiler selection can be simplified.

• Difficulty: Easy to Medium
• Languages: Tcl
• Potential mentors: mcalhoun
• Importance: Low

Announcements distributed over the ports tree

Some announcements about configuration changes could be presented to users when they update their ports tree. That involves a mechanism to add news items to the ports tree and a new port news command that allows the user to read them (and also mark them as read). Each news item could define conditions when they should be shown to the user, for example depending on the OS version or if a specific port is installed. It will need a new API in macports1.0 to check for unread items, so the port client can poll it, for example when using a port news command. Additionally, these news items should also be available on the web.

As an example, there is a similar feature in ​Gentoo Portage. You can refer to these emails as well - ​March 21 and ​March 24, 2018.

• Difficulty: Easy
• Languages: Tcl, HTML
• Potential mentors: ?
• Importance: High

Improve startupitem code

MacPorts has the ability to automatically generate startup items for the current platform. For OS X, these are plist files for launchd which will be installed as /Library/LaunchDaemons/org.macports.*.plist. The current code would need a little care and could make use of options that have been added in recent releases of launchd.

Features that could be useful include (but are not limited to):

• Not using daemondo if the daemon works fine under launchd without it
• Ability to install multiple plists
• Support for LaunchAgents as well as LaunchDaemons
• Installing plists in ~/Library for non-root installs if the user wants
• only modify specific XML tags to avoid clobbering additions by user
• Support startupitems in standalone binary packages (currently a brutal hack is used to include daemondo in such packages, see #43648)

It would be great to write some shorthand in a portfile that builds an XML launchd plist.

• Difficulty: Easy
• Languages: Tcl, C
• Potential mentors: larryv, pixilla
• Importance: Low

Implement fakeroot functionality

Currently, MacPorts uses root privileges in the destroot phase. That should be replaced by a system that runs as the macports user but intercepts all operations that would require root privileges (chown/chmod/etc.) and record the resulting permissions in a database.

The existing functionality of trace mode in darwintracelib1.0 could be leveraged for this task.

• Difficulty: Medium
• Languages: Tcl, C
• Potential mentors: ?
• Importance: Medium

Speed up trace mode

Trace mode is a library preloading-based sandbox used to hide files that a port does not depend on or that are not part of a standard system's installation (such as /usr/local). This can avoid problems due to incompatible user-installed software and avoid "automagic" dependencies and increase the reproducibility of builds.

Unfortunately, enabling trace mode adds a significant performance penalty to the build process. However, the trace mode code can certainly be optimized using appropriate cache data structures, such as a modified ​Trie. Your task would be to identify the performance bottlenecks, draft appropriate caching data structures and implement them.

• Difficulty: Medium to Hard
• Programming languages: Tcl, C
• Potential mentors: cal
• Importance: Medium

Auto-detection of build dependencies

When creating a new portfile one of the problems is always the specification of the complete (and preferably minimal) list of build dependencies, especially when one starts with a complete install where most dependencies are already available.

It is possible to invert the trace mode logic so that it detects all files a configure and/or build process accesses, in ${prefix} but outside of the port's build directory. This information can then be used to generate a dependency tree and information from the registry can then be used to simplify that tree so that it only lists direct dependencies. It can be combined with the above project. Consult mentor.

• Difficulty: Easy to Medium
• Programming languages: Tcl, C
• Potential mentors: cal
• Importance: Low

Buildbot ideas

NA

More Ideas/Hints for your own ideas

Shell environment

Add support for providing basic and port-provided environmental services to users in the ~/.profile, ~/.cshrc, and ~/.xinitrc files, so that instead of manipulating the user's .profile to modify certain paths, the installer could append "source /opt/local/etc/bash.rc" to the end of a user's .profile file and that bash.rc would source all the files in /opt/local/etc/bash.d.

• Difficulty: Easy
• Potential mentors: raimue
• Importance: Low

Improve port bump

Homebrew has brew bump-formula-pr. Such functionality saves a lot of work when updating many ports. Bumping ports using PortGroup like GitHub and bitbucket should also be supported. Existing revision should be reset or removed interactively. A suggested commit message for the update should be shown.

Use cases (pseudo commands):

• port bump [[portname | pseudo-portname | port-expressions | port-url]] bumps checksums only
• port bump [[portname | pseudo-portname | port-expressions | port-url]] @<version> bumps version and checksums
• port bump --livecheck [[portname | pseudo-portname | port-expressions | port-url]] bumps both with livecheck result if ${version} == ${livecheck.version}

This has been partially implemented in GSoC 2019. See ​https://trac.macports.org/wiki/SummerOfCode/bump and #53851 for more details

• Difficulty: Easy
• Languages: Tcl, C
• Potential mentors: TBD
• Importance: Medium

Parallel execution

When an action will run targets on multiple ports, run them in parallel when possible and sensible (requires tracking dependencies between both targets and ports and figuring out the maximum reasonable parallelism, e.g. several ports can fetch at once on a fast connection but you only want one 'make -j8' at a time).

• Difficulty: Challenging
• Languages: Tcl, C
• Potential mentors: ?
• Importance: Medium

Migrate muniversal into base (lipo merging)

Integrate the muniversal portgroup​ into the base. Not just a direct copy-and-paste, but in a way that makes sense and preserves the way portfiles are expected to behave (which the current portgroup doesn't).

• Difficulty: Medium
• Languages: Tcl, C
• Potential mentors: TBD
• Importance: Medium

Documentation and website

Improve MacPorts documentation, website and Trac system. Note that pure documentation proposals are not allowed by Google.

• Difficulty: Easy to difficult
• Languages: PHP, Python
• Potential mentors: larryv

New Ideas

1. Add sanity tests
2. Improve UX for macports command line and colors
3. Improve ports web application - medium
4. pypi2port upt
5. buildbot user interface improvements - medium
6. coloring - easy
7. Rewrite parts of macports in Python - medium - ijackson

Contacting us

There are several ways to contact us:

• Dropping a mail to the MacPorts-dev mailing list will get you most attention. Note that you have to be subscribed to the list in order to send mail to it. We recommend you create a filter matching the header line List-Id: macports-dev.lists.macports.org and sort all the emails matching this filter into a separate folder. When sending inquiries about Google Summer of Code, we would welcome if you included "GSoC" in the subject of your mail.
• You can get quick feedback and less formal discussion by joining the #macports channel on the ​Freenode IRC network. You'll need an IRC client to do so – ​Colloquy is a popular choice for OS X. Please note that due to timezones and day jobs you might not receive an answer right away. Most users will read your messages when they return and answer as soon as they can. Be prepared to wait a few hours.
• Feel free to contact any potential mentor via email directly. You can get the email address by appending @macports.org to the handle listed in #Mentors above.

In general, don't hesitate to contact us – we're here to help you and eager to mentor motivated students in this year's GSoC!

Admins

Append @macports.org for email.

Name	Email	Area
Umesh Singla	umeshksingla	Administrator
Mojca Miklavec	mojca	Co-admin
Jackson Isaac	ijackson	Co-admin

Mentors

The following committers have agreed to be mentors for GSoC 2019 (append @macports.org for the email if it is missing)

Name	Email	Area
Mojca Miklavec	mojca	Mentor
Marcus Calhoun-Lopez	mcalhoun	Mentor
Michael Dickens	michaelld	Mentor
Umesh Singla	umeshksingla	Mentor
Pierre Tardy	tardyp@…	Mentor/Buildbot contact