= Google Summer of Code 2014 = {{{ #!comment #!div style="clear:left; display:block; width:100%; margin:0; padding:0;" Unfortunately, we have not been accepted for GSoC 2013. However, any contributions and enhancement proposals are welcome! Please see [http://guide.macports.org/#development the guide] and subscribe to the MailingLists! }}} {{{ #!comment #!div style="clear:left; display:block; width:100%; margin:0; padding:0;" We have been accepted for GSoC 2013. Further contributions and enhancement proposals are welcome! Please see [http://guide.macports.org/#development the guide] and subscribe to the MailingLists! }}} {{{ #!comment #!div style="clear:both; display:block; width: 75%; margin:0 auto; background-color: lightyellow; border: 2pt solid; font-weight:bold; text-align: center; font-size:120%;" MacPorts has applied for Google Summer Of Code 2013! \\ Stay tuned! }}} {{{ #!comment #!div style="clear:both; display:block; width: 75%; margin:0 auto; background-color: lightgreen; border: 2pt solid; font-weight:bold; text-align: center; font-size:120%;" We are accepting applications! Apply for Google Summer Of Code 2013 now! [[BR]] Deadline is April 8, 19:00 UTC [[BR]] [http://www.google-melange.com/gsoc/org/google/gsoc2013/macports MacPorts at GSoC website] }}} [[PageOutline]] This is the MacPorts Project’s page for [http://code.google.com/soc/ Google Summer of Code]. {{{ #!div style="margin: 5px auto; text-align: center;" [[Image(https://www.neverpanic.de/documents/GoogleSummer_2014logo_avatar.png, 350, link=https://www.google-melange.com/gsoc/homepage/google/gsoc2014, title=Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License)]] }}} Information about the past years can be found at SummerOfCodeArchive. == Applications for GSoC == The window for submitting mentoring organization applications has started and closes on '''14 February at 19:00 UTC'''. === General info === For future reference you may check the [https://www.google-melange.com/ Google SoC website]. You will find more information on their page on [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Advice for Students]. The official [http://www.google-melange.com/gsoc/events/google/gsoc2014 timeline] should be consulted for the other dates. There are several things to consider. We are willing to support and mentor students who want to gain an 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. Motivated students do not necessarily need to know Tcl language beforehand, especially if they already know several scripting languages such as Python, Ruby, PHP or Perl. === For the MacPorts Project === The best way to apply is to first make contact with us, either by sending a mail to the MacPorts developer [http://lists.macosforge.org/mailman/listinfo/macports-dev "mailing list"], to the potential mentors listed below, or to IRC members on #macports on [http://freenode.net/ FreeNode]. 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. What you should do before handing in an application: * Get familiar with the MacPorts Project resources. Especially [GetMacPortsSource check out the code] and [http://guide.macports.org read the guide]. * Read the [http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html Tcl Tutorial] * Subscribe to the mailing lists [http://lists.macosforge.org/mailman/listinfo/macports-dev macports-dev] and [http://lists.macosforge.org/mailman/listinfo/macports-users macports-users] if you do not already read them. Don't be too shy to post. * '''Get in contact! ''' Most important is to discuss your ideas with potential mentors via private e-mail, the MacPorts development list, or the IRC channel before applying. == Mentors == The following committers have agreed to be mentors for GSoC 2013 (append `@macports.org` for e-mail) ||= Name =||= Email =||= Area =|| ||= Jeremy Lavergne =|| snc || Administrator || ||= Clemens Lang =|| cal || Backup Admin, Mentoring if needed (especially for base) || ||= Rainer Müller =|| raimue || Mentoring for base, port groups, ports, ... || ||= Lawrence Velázquez =|| larryv || Backup to the backup admin; mentoring for port[group]s, documentation, website || == Students == Marius Coțofană’s project has been accepted for GSoC 2013! He aims to [http://www.google-melange.com/gsoc/project/google/gsoc2013/marius_coto/13001 improve the MacPorts test framework]. == Tasks == 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. === Core tasks === ==== Binaries ==== #binaries MacPorts provides binaries but needs several enhancements. This task would include updating the chroot mechanism (ceased being functional with Snow Leopard) and adding support for variants. (See also [[MPAB|MacPorts AutoBuild]].) * Difficulty: Relatively challenging to challenging * Languages: Tcl * Potential mentors: TBD ==== Dependency calculation using SAT solving ==== #dependencies This task consists of implementing a new dependency engine for MacPorts. The current dependency engine properly deals with installing packages, but it does not deal satisfactorily with [[ticket:126|dependencies on variants]] and versions, uninstalling and upgrading. This task requires understanding the dependency relations (required for fetching, building, configuring; static and dynamic linking; dependence at runtime). Instead of re-inventing the wheel it might be helpful to use software available to solve the problem of dependency calculation, e.g. by implementing an interface to a [http://www.mancoosi.org/cudf/ Common Upgradeability Description Format]-based SAT solver. Such a solver could generate an execution plan we could propose to the user and finally execute when confirmed. For this task, the MacPorts concept of variants needs to be transformed into a representation the SAT solvers will be able to optimize. If time permits, rolling back on failed updates can also be implemented. There is also a [browser:trunk/dports/devel/libCUDF/Portfile libCUDF] port that might be helpful to look at. * Difficulty: Challenging * Languages: Tcl, C * Potential mentors: cal ==== Remove dependency on Xcode ==== #xcode MacPorts currently requires a full Xcode installation, even if the user only wishes to install prepackaged binaries or compile ports that do not use Xcode projects for building. This task be as simple as allowing MacPorts to install binary packages without Xcode present, or as complex as enabling MacPorts to be completely self-sufficient (not requiring Xcode or the Command Line Tools at all). * Difficulty: Medium to very challenging * Languages: Tcl, C * Potential mentors: TBD ==== MacPorts port for self-management ==== #self-management The MacPorts port should be the source for updating a user’s MacPorts installation. Currently the MacPorts port is used to build the .dmg installer for MacPorts that is used for the initial installation of MacPorts, and port uses the “selfupdate” mechanism for maintaining the MacPorts installation. The selfupdate mechanism is (at least not documented as such) not accessible through the MacPorts API and does not use the MacPorts mechanisms for maintaining ports. * Difficulty: Challenging * Languages: Tcl, C * Potential mentors: TBD ==== Generating Portfiles ==== There are multiple tasks related to the generation of Portfiles. Some of these may not be enough work for a full summer project, so they could be combined for proposals freely when the applying student wants to. ===== Perl modules integration from CPAN ===== #cpan2port There has been [[browser:contrib/cpan2port|an attempt]] to write a script for automatic generation of Portfiles from CPAN. This would simplify the maintenance of Perl modules in MacPorts. Revive this project and finish the script or rewrite it. Resources: * http://www.gentoo.org/proj/en/perl/g-cpan.xml * http://search.cpan.org/~bingos/CPANPLUS-0.9001/bin/cpan2dist * http://packages.debian.org/stable/dh-make-perl * Difficulty: Easy to medium * Languages: Perl, probably Tcl * Potential mentors: TBD ===== Read packages from Python's PIP (pip2port) ===== #pip2port MacPorts should be able to more readily install python packages from pip. We don't want to integrate the build/installation process of PIP, simply parse information or eggs it provides for various packages. This information will then be used to generate a Portfile, akin to [[browser:contrib/cpan2port/cpan2port|cpan2port]]. There may be instances where MacPorts package names don't match up with pip’s. In this case, pip should be the authority and all improperly named MacPorts packages should be replaced by a renamed copy. Verbose automation of this step, akin to the portcheckup script, is ideal. The [[browser:contrib/portfile-gen/portfile-gen|portfile generator]] might be helpful. * Difficulty: Medium * Languages: Tcl, Python, C * Potential mentors: snc ===== Read packages from other various package managers ===== #foo2port As above with the pip2port proposal, except with other package managers, such as [http://opam.ocamlpro.com/ opam] for ocaml packages, [http://www.haskell.org/cabal/ cabal] for haskell, [http://luarocks.org/ luarocks] for lua, [https://npmjs.org/ npm] for node.js, and so on. * Classification: Medium * Languages: Tcl, C, OCaml, Haskell, Lua, Node.js, etc. * Potential mentors: TBD ===== Generate Portfiles with auto-detection of build toolchain ===== #portfile-gen To ease creation of new ports, the helper script [http://trac.macports.org/browser/contrib/portfile-gen/portfile-gen portfile-gen] is able to generated a Portfile stub by taking the name, version and possible a port group as input. This should be extended to handle more things automatically. Lots of options in a Portfile need to be figured out by the maintainer, although they could be extracted automatically from the source. With just a URL to the tarball of a software, portfile-gen can usually automatically extract the name and the version from the filename. Furthermore, the master_sites and distfiles can be derived from the URL, with special handling for sites like sourceforge/gnu/etc. However, it should also be possible to specify this later and start portfile-gen with a pre-downloaded tarball. The checksums for the distfiles can be generated after fetching the tarball (portfile authors should be warned to verify these with upstream!) and even more information can be collected when extracting the tarball. Different build systems usually have a unique way to be detected. For example, if a `configure.ac` or `configure.in` exists, but no `configure`, we need to run autoconf. If there is also a `Makefile.am`, but no `Makefile.in` this is using automake and we should better use `autoreconf` instead. If there is a `CMakeLists.txt`, we should include the cmake port group. If there is just a Makefile, but no `configure`, chances are high we can skip the configure phase with `use_configure no`. There are a lot more of such heuristics similar the examples above. This tasks includes implementing a framework where more of these indicators and the resulting actions can be added. The goal of this task is to create an easy-to-use Portfile generator that derives the basic information of a Portfile automatically. This should lower the amount of lines to be written by Portfile authors and lower the barrier for writing the first Portfile. If this is implemented with Tcl modules in mind, this could probably even go into base as a `port new` or `port create` command. * Classification: Medium * Languages: Tcl * Potential mentors: raimue ==== Increase test coverage ==== #testing MacPorts currently includes a [[source:trunk/base/tests|test framework]] to test features of the infrastructure. However, the tests do not cover all the code. This task consists of extending the test framework and could be broadened to develop a code coverage technology for MacPorts to make the infrastructure more robust to future changes. * Difficulty: Relatively easy to very challenging * Languages: Tcl, C * Potential mentor: raimue ==== Configuration and environment selftest ==== #envcheck Add a command to check current setup for common pitfalls (e.g. stuff in `/usr/local`), inspired by Homebrew’s `brew doctor` functionality. * Difficulty: Easy * Languages: Tcl * Potential mentors: larryv ==== Improve Trace mode ==== #tracemode Improve trace mode to the point where developers (and the build server) could run with it always turned on. This currently requires fixing some (minor) remaining bugs in the trace code itself, adjust the build system to always build the tracing library as universal binary and improving the Tcl backend of trace mode (e.g. by adding more features like a list of accessed files, speeding up the lookup by using better data structures). * Difficulty: Medium to Easy * Programming languages: Tcl, C * Potential mentors: cal ==== Improve startupitem code ==== #startupitem 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 which 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 * Difficulty: Easy * Languages: Tcl, C * Potential mentors: larryv ==== Reclaim disk space ==== #reclaim Improve `port clean` to be able to delete distfiles for a specified version, and all distfiles not needed by currently installed versions of ports. In general, add an action for reclaiming disk space, which would delete old distfiles and archives and uninstall inactive ports (and anything else that would help). * Difficulty: Easy * Languages: Tcl, C * Potential mentors: larryv ==== Parallel execution ==== #parallel 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: Very challenging * Languages: Tcl, C * Potential mentors: TBD ==== Migrate muniversal into base (lipo merging) ==== #muniversal Integrate the [[source:trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl|muniversal portgroup]] into 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 ==== Improve fetching from version control ==== #fetchtypes Make cvs/svn/git/hg/bzr fetch types checkout into the distfiles dir and then export into the work dir, to [[ticket:16373|avoid having to re-fetch]] after cleaning the work directory. * Difficulty: Easy * Languages: Tcl, C * Potential mentors: larryv ==== Interactive port command ==== #interactive Write an interactive command-line tool that can be used instead of the non-interactive port(1). (The existing "interactive mode" of port(1) is actually just batch mode reading from stdin, and is not really interactive.) Factor out code used by both tools into a shared module. An interactive tool would ask for user input to resolve many situations that cause port(1) to simply error out. For example, if you try to install a port and one of its dependencies conflicts with something already installed, it could ask if you want to deactivate the installed one and its dependents. * Difficulty: Medium * Languages: Tcl, C * Potential mentors: TBD === Secondary tasks === ==== Portfiles ==== #portfiles Sweep through all Portfiles and look for useful opportunities to add more built-in Tcl functions that make Portfiles more (usefully) terse, powerful, flexible or easier to write. I'm sure there is an entirely family of helper functions yet to be written here. This might also include porting additional packages to MacPorts and cleaning up or removing obsolete ports. * Classification: Medium * Language: Tcl * Potential mentors: larryv ==== Documentation and website ==== #docs Improve MacPorts [query:status!=closed&component=guide|server/hosting|website|wiki 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 ==== Shell environment ==== #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`. This task alone is most probably not enough for the whole Summer Of Code. * Difficulty: Easy * Potential mentors: raimue {{{ #!comment # Listing already done tasks here, maybe parts of this could spin-off a new project idea # Done 2009 ==== Logging ==== #logging Currently MacPorts has no notion of logging of build activities of a given port or sets of ports. When a build is attempted but an error keeps it from completing, there's no way to track the problem other than the build progress that was output to the terminal, if verbose mode was requested in the first place. Otherwise, the build environment has to be pruned and the build attempted once again to even get a look at the precise error message. This is particularly problematic when automated builds are attempted, since there's usually no one around to have a look at the failure spew. An infrastructure to remedy this situation and endow MacPorts with a rich set of logging capabilities has to be developed to open up the door to true automated build runs of large sets of ports and thus to packaging of binaries, since with logging we'd have a fully reliable way of catching, reporting and processing of all sorts of fetch/configure/build/destroot/install/etc errors. This could be extended with the interaction with a server side application like MPWA that could consume these logs (read MPWA proposal). A more detailed draft of this task can be found on the LoggingProposal page. Classification: medium task to relatively challenging[[BR]] Programming languages: Tcl and C[[BR]] Potential mentor: blb }}} {{{ #!comment # Removed ideas which do not fit to our plans anymore # Will be obsolete and no longer be possible with the images-and-archives branch ==== Images (Pkgview, depot-to-depot dependencies) ==== #images MacPorts implements what we call the Image mode where software are stored in a depot (e.g. `/opt/local/var/db/dports/software/gawk/3.1.5_2/opt/local/bin/gawk`). For the moment, this functions like an archive and files are hardlinked to their active location (/opt/local/bin/gawk). If port A depends on dynamic library B.dylib from port B, it actually links to /opt/local/lib/B.dylib. The idea of this task is to figure out a way for port A to be linked to the library in the depot and to work even if port B is not active. That is to say that if port foo depends on version 1.2.3 of port bar, it should be compiled and linked in such a way that it's wired to the depot location of bar, not the "activated" location. That will finally fix the fragility problem where deactivating port bar vers n-1 in order to install port bar vers n (because other things depend on n) won't also require breaking everything that relies on n-1. This mechanism also has additional advantages such as limiting the unavailability time to a minimum, especially when upgrading libraries every other package depends on (such as gettext). Classification: challenging to very challenging task[[BR]] Programming language: Tcl[[BR]] Potential mentor: TBD }}}