41 | | 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. |
| 41 | There are several things to consider. We are willing to support and |
| 42 | mentor students who want to gain an experience by working on the |
| 43 | MacPorts Project. We have many ideas for potential internship subjects, |
| 44 | yet we are open to anything that is both interesting and relevant to |
| 45 | MacPorts. Motivated students do not necessarily need to know Tcl |
| 46 | language beforehand, especially if they already know several scripting |
| 47 | languages such as Python, Ruby, PHP or Perl. |
45 | | 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]. |
| 51 | The best way to apply is to first make contact with us, either by |
| 52 | sending a mail to the MacPorts developer |
| 53 | [http://lists.macosforge.org/mailman/listinfo/macports-dev "mailing list"], |
| 54 | to the potential mentors listed below, or to IRC members on #macports on |
| 55 | [http://freenode.net/ FreeNode]. |
70 | | 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. |
71 | | |
72 | | 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. |
| 80 | This is a list of some potential tasks that student GSoC members could |
| 81 | undertake. These are just ideas, and while they express our current |
| 82 | concerns, we are open to blue-sky projects related to MacPorts. |
| 83 | |
| 84 | Please note that this list is absolutely '''not exclusive'''! If you |
| 85 | have any idea about what you want to see improved in MacPorts, you are |
| 86 | free to propose this as your own project. In any case, we recommend you |
| 87 | talk to mentors before writing your application. |
86 | | 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). |
87 | | |
88 | | 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. |
89 | | There is also a [browser:trunk/dports/devel/libCUDF/Portfile libCUDF] port that might be helpful to look at. |
| 104 | This task consists of implementing a new dependency engine for MacPorts. |
| 105 | The current dependency engine properly deals with installing packages, |
| 106 | but it does not deal satisfactorily with [[ticket:126|dependencies on variants]] |
| 107 | and versions, uninstalling and upgrading. This task requires |
| 108 | understanding the dependency relations (required for fetching, building, |
| 109 | configuring; static and dynamic linking; dependence at runtime). |
| 110 | |
| 111 | Instead of re-inventing the wheel it might be helpful to use software |
| 112 | available to solve the problem of dependency calculation, e.g. by |
| 113 | implementing an interface to a |
| 114 | [http://www.mancoosi.org/cudf/ Common Upgradeability Description Format]-based |
| 115 | SAT solver. Such a solver could generate an execution plan we could |
| 116 | propose to the user and finally execute when confirmed. For this task, |
| 117 | the MacPorts concept of variants needs to be transformed into |
| 118 | a representation the SAT solvers will be able to optimize. If time |
| 119 | permits, rolling back on failed updates can also be implemented. There |
| 120 | is also a [browser:trunk/dports/devel/libCUDF/Portfile libCUDF] port |
| 121 | that might be helpful to look at. |
97 | | 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). |
| 129 | MacPorts currently requires a full Xcode installation, even if the user |
| 130 | only wishes to install prepackaged binaries or compile ports that do not |
| 131 | use Xcode projects for building. This task be as simple as allowing |
| 132 | MacPorts to install binary packages without Xcode present, or as complex |
| 133 | as enabling MacPorts to be completely self-sufficient (not requiring |
| 134 | Xcode or the Command Line Tools at all). |
105 | | The MacPorts port should be the source for updating a user’s MacPorts installation. |
106 | | |
107 | | 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 |
| 142 | The MacPorts port should be the source for updating a user’s MacPorts |
| 143 | installation. |
| 144 | |
| 145 | Currently the MacPorts port is used to build the .dmg installer for |
| 146 | MacPorts that is used for the initial installation of MacPorts, and port |
| 147 | uses the “selfupdate” mechanism for maintaining the MacPorts |
| 148 | installation. The selfupdate mechanism is (at least not documented as |
| 149 | such) not accessible through the MacPorts API and does not use the |
| 150 | MacPorts mechanisms for maintaining ports. |
128 | | 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]]. |
129 | | |
130 | | 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. |
131 | | |
132 | | The [[browser:contrib/portfile-gen/portfile-gen|portfile generator]] might be helpful. |
| 174 | MacPorts should be able to more readily install python packages from |
| 175 | pip. We don't want to integrate the build/installation process of PIP, |
| 176 | simply parse information or eggs it provides for various packages. This |
| 177 | information will then be used to generate a Portfile, akin to |
| 178 | [[browser:contrib/cpan2port/cpan2port|cpan2port]]. |
| 179 | |
| 180 | There may be instances where MacPorts package names don't match up with |
| 181 | pip’s. In this case, pip should be the authority and all improperly |
| 182 | named MacPorts packages should be replaced by a renamed copy. Verbose |
| 183 | automation of this step, akin to the portcheckup script, is ideal. |
| 184 | |
| 185 | The [[browser:contrib/portfile-gen/portfile-gen|portfile generator]] |
| 186 | might be helpful. |
140 | | 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. |
| 194 | As above with the pip2port proposal, except with other package managers, |
| 195 | such as [http://opam.ocamlpro.com/ opam] for ocaml packages, |
| 196 | [http://www.haskell.org/cabal/ cabal] for haskell, [http://luarocks.org/ luarocks] |
| 197 | for lua, [https://npmjs.org/ npm] for node.js, and so on. |
148 | | 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. |
| 205 | MacPorts currently includes a [[source:trunk/base/tests|test framework]] |
| 206 | to test features of the infrastructure. However, the tests do not cover |
| 207 | all the code. This task consists of extending the test framework and |
| 208 | could be broadened to develop a code coverage technology for MacPorts to |
| 209 | make the infrastructure more robust to future changes. |
164 | | 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). |
| 226 | Improve trace mode to the point where developers (and the build server) |
| 227 | could run with it always turned on. This currently requires fixing some |
| 228 | (minor) remaining bugs in the trace code itself, adjust the build system |
| 229 | to always build the tracing library as universal binary and improving |
| 230 | the Tcl backend of trace mode (e.g. by adding more features like a list |
| 231 | of accessed files, speeding up the lookup by using better data |
| 232 | structures). |
172 | | 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. |
| 240 | MacPorts has the ability to automatically generate startup items for the |
| 241 | current platform. For OS X, these are plist files for launchd which will |
| 242 | be installed as `/Library/LaunchDaemons/org.macports.*.plist`. The |
| 243 | current code would need a little care and could make use of options |
| 244 | which have been added in recent releases of launchd. |
187 | | 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) |
| 259 | Improve `port clean` to be able to delete distfiles for a specified |
| 260 | version, and all distfiles not needed by currently installed versions of |
| 261 | ports. In general, add an action for reclaiming disk space, which would |
| 262 | delete old distfiles and archives and uninstall inactive ports (and |
| 263 | anything else that would help). |
195 | | 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) |
| 271 | When an action will run targets on multiple ports, run them in parallel |
| 272 | when possible and sensible (requires tracking dependencies between both |
| 273 | targets and ports and figuring out the maximum reasonable parallelism, |
| 274 | e.g. several ports can fetch at once on a fast connection but you only |
| 275 | want one 'make -j8' at a time). |
234 | | 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. |
| 325 | Sweep through all Portfiles and look for useful opportunities to add |
| 326 | more built-in Tcl functions that make Portfiles more (usefully) terse, |
| 327 | powerful, flexible or easier to write. I'm sure there is an entirely |
| 328 | family of helper functions yet to be written here. This might also |
| 329 | include porting additional packages to MacPorts and cleaning up or |
| 330 | removing obsolete ports. |
250 | | 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`. |
| 348 | Add support for providing basic and port-provided environmental services |
| 349 | to users in the `~/.profile`, `~/.cshrc`, and `~/.xinitrc` files, so |
| 350 | that instead of manipulating the user's .profile to modify certain |
| 351 | paths, the installer could append "`source /opt/local/etc/bash.rc`" to |
| 352 | the end of a user's .profile file and that bash.rc would source all the |
| 353 | files in `/opt/local/etc/bash.d`. |