-
-
Notifications
You must be signed in to change notification settings - Fork 735
GSoC Project Ideas
So you're looking for inspiration for your Google Summer of Code project application? Here's a collection of ideas to get you started. You don't have to take something from this list; If you've got an interesting idea of your own, feel free to suggest it. This is a list of pre-approved ideas.
If you want to propose something of your own, keep in mind that we're looking for contributions to improve BeeWare libraries, not projects that use BeeWare libraries. Proposals to "build an app that does X using Toga" will not be accepted.
BeeWare is an umbrella covering a large number of projects. Here are some of the areas of particular interest for the Google Summer of Code. If you want any more details about these projects, jump onto our Gitter channel and ask!
Toga is a BeeWare's cross-platform native widget toolkit.
-
Improve widget support for a particular backend Support for Android and Windows, in particular, are lagging behind other platforms.
-
Develop a code display/editing widget The ability to display syntax highlighted code is a complex feature that is not currently supported. Developing and API for such a widget, and an implementation for one or more platforms, would be a significant, but very helpful undertaking.
-
Implement a testing harness for one of the supported backends GUI code is notoriously hard to test. At present, Toga does not have a good way to validate that changes to a backend don't break usage of a widget in practice. Providing a testing harness that would allow us to automatically validate API changes would be extremely helpful.
-
Improve the dummy testing API Toga's abstraction API makes it possible to inject a testing layer into end-user code. Instead of developing against a literal GUI layer, Toga has a "dummy" backend that implements all the required APIs, but doesn't actually display anything on the screen. This could allow end-users to easily develop unit tests for their application code - if only the dummy API had testing features.
BeeKeeper is BeeWare's Continuous Integration service. BeeWare has some very unusual testing requirements; BeeKeeper gives us great flexibility in how we run our tests, while controlling our hosting costs.
There are many areas where BeeKeeper's capabilities could be improved:
-
Migrate from AWS ECS to Kubernetes BeeKeeper currently uses Amazon's Elastic Container Service to deploy test jobs. While this works, it is an API that is specific to Amazon. We would like to migrate to using Kubernetes. This would minimise our exposure to Amazon-specific APIs, and hopefully provide an easier path to supporting other deployment hosts (Google Cloud, Linode, Digital Ocean etc).
-
Enable desktop operation of a BeeKeeper cluster BeeKeeper is currently used the same ways as any classical CI setup - you submit a pull request, and a build job is issued on a communal cloud server. However, because we're using Docker behind the scenes, it should be possible to deploy a BeeKeeper deploy job anywhere that supports Docker. Having a desktop CI environment that exactly matches the communal CI server would be a significant improvement.
-
Reimplement the BeeKeeper UI in Toga The ultimate proof of Toga's capabilities would be to use them to build a non-trivial application that also has a web UI. This will inevitably involve changes to Toga itself (especially fixes to the Django/Web backend), but it would be a high visibility project demonstrating Toga's capabilities.
VOC is a transpiler that converts Python code into Java class files so Python code can run in the JVM. This enables you to run Python code anywhere that there is a JVM - which includes Android phones. VOC exposes Java classes as Python classes, so you can extend Java code, implement Java interfaces, and access Java APIs from within Python.
Working on VOC requires a working knowledge of Java programming. This includes basic syntax and semantics, and the capabilities of the standard library when dealing with collections, primitive data types, and so on.
Some project ideas:
-
Complete the implementation of one or more builtin data types. Pick a builtin data type (
str,float,int, etc), and work on that data type until the API provided by Batavia/VOC is the same as that provided by CPython. Build a list of all the operations that are valid on a given data type, and all the methods you can invoke on a data type, and work your way down that list, one operator and data type at a time. -
Implement part of the standard library. Pick a module in the standard library (e.g.,
json), and re-implement that library. Depending on which library you choose, you may be able to re-use parts of the CPython implementation; or, you may have to start from scratch and write a native implementation of the documented API. -
Issue #301 Implement asyncio support Python 3.4 introduced asynchronous I/O support to the Python core language. Providing asyncio support requires low level integration with Java's networking and event stack. We would like to add this support to VOC, either for the Android VM, the Oracle VM, or both.
-
Issue #14 Advanced Add support for StackMapFrames in Java class files.
-
Issue #75 Advanced: Optimize Java bytecode generated by VOC. While VOC is able to generate class files from almost any Python source code, it isn't always efficient bytecode. We need someone to optimise the compiler to generate more efficient Java bytecode.
Batavia is a bytecode machine, written in Javascript, that allows CPython bytecode to run in a browser. This means any server-side logic (say, validation logic for a credit card field) can be shipped to the browser and run exactly the same as it would on the server. You also have full access to the DOM, and any native Javascript code, which can be accessed as native Python objects, so if you want, you can write a web app with dynamic on-screen behavior without ever writing a line of Javascript.
Working on Batavia requires a working knowledge of Javascript programming. Knowledge of Rollup and emerging ES201X language extensions would be beneficial, but not essential.
Some project ideas:
-
Complete the implementation of one or more builtin data types. Pick a builtin data type (
str,float,int, etc), and work on that data type until the API provided by Batavia is the same as that provided by CPython. Build a list of all the operations that are valid on a given data type, and all the methods you can invoke on a data type, and work your way down that list, one operator and data type at a time. -
Issue #410 Implement part of the standard library. Pick a module in the standard library (e.g.,
json), and re-implement that library. Depending on which library you choose, you may be able to re-use parts of the CPython implementation; or, you may have to start from scratch and write a native implementation of the documented API. -
Implement asyncio support Python 3.4 introduced asynchronous I/O support to the Python core language. Providing asyncio support requires low level integration with ES2016's async/await features. We would like to add this support to Batavia, including exposing Python APIs for making HTTP requests.
-
Optimize performance While Batavia is able to execute any CPython bytecode file, the core bytecode machine isn't always fast. We need someone to optimise the interpreter to generate more efficient Java bytecode. An implementation using ASM.js/WASM may be one option.
Ouroboros is a pure Python implementation of the Python standard library. It is used at runtime by Batavia and VOC. Eventually, the aim is to expand Ouroboros
-
Provide a pure python implementation of one or more modules from the standard library that are implemented in C.
-
Create a Python compliance test suite There isn't currently any way to test that a Python implementation is "compliant". The closest thing that is available is CPython's test suite; this code could be adapted into a format that any Python implementation could run to confirm compliance.
Colosseum is a pure Python implementation of the CSS box model. It can be used by Toga to lay out widgets.
- Improve CSS standard compliance for the rendering engine.
BeeWare has a history of mentoring contributors to their first open source contributions. We've been able to take contributors with very little coding experience and get them a commit in a BeeWare project. We'd expect to see the same for a GSoC student. The work can be delivered in small pieces; we'd expect to see small pull requests submitted regularly for review as candidates for merging into the master branch. Completing a single data type and all it's interfaces should be entirely achievable; completing several data types is not out of the question, depending on the student. If the student's work is of a high enough quality, they may even be offered a position on the maintainer team.
The primary mentors for this project will be Russell Keith-Magee, Philip James, and Elias Dorneles. Other members of the BeeWare core team may provide assistance and guidance.