It is still under construction and content may change. Do not rely on the information on this page.
Problem description
By their actions, developers have voted overwhelmingly in favour of the use of cross-platform language specific tooling for collaborative development across Windows, Mac OS X, Linux and other client platforms.
Part of the mission of the Environments & Stacks Working Group is to help ensure that as a development platform, Fedora facilitates this development model, while also providing tools to help mitigate its risks.
One approach we're exploring for this is to create Fedora level repositories that allow access using the relevant ecosystem specific tools, while providing all the usual distro level assurances regarding licensing and build service integrity.
This activity is part of a broader discussion of Env_and_Stacks/Projects/UserLevelPackageManagement. As noted there, many language ecosystems don't support the notion of redistribution at all. In these cases, republishing under the same name from a Fedora specific repo would be problematic. The likely near term approach to these communities will be to just place them in the "too hard" basket, and focus on ecosystems where the tools are in place to handle curated redistribution without conflict.
Pilot ecosystems
Two ecosystems will be used to pilot the notion of Fedora specific downstream repositories using native ecosystem tooling. For ecosystems not covered by the pilot, Environments & Stacks WG involvement will be limited to helping to ensure that the relevant ecosystem tools are readily available to developers running Fedora Workstation and/or deploying to Fedora Server or Fedora Cloud.
The two ecosystems chosen for the pilot are:
- Python (making use of devpi and the explicit redistributor support in PEP 440)
- Maven/Java (technical details still TBD)
Both pilots are currently expected to use ecosystem specific server components. This may not be sustainable long term, in which case it may prove necessary to switch to a plugin based server model based on [Pulp] (for example, the [Pulp Python plugin]).
Ideally, the ecosystem specific formats will be built from source in Koji. The Koji developers are already looking into support for building Java JAR files in addition to RPMs.
Pilot objectives
The main goal of the pilot projects is to decide whether or not a model that involves provide Fedora-endorsed language specific repositories is likely to be sustainable long term.
If the verdict is that this is a good path to pursue, then the next step would be propose a change (probably in the Fedora 23 time frame) to the review process to allow packages to be reviewed for inclusion in the languages specific repositories *without* first repackaging them as RPMs. That would change the package inclusion process to look something like:
1. Licensing & build review -> available in language specific repository
2. Repackage as RPM -> also available via COPR (& Fedora Playground if desired)
3. Meet Fedora packaging guidelines -> also available in main Fedora repositories (& EPEL if desired)
Python (devpi) pilot
Project leader: Bohuslav (Slavek) Kabrda
Team members: Nick Coghlan
Pilot server: 209.132.184.166 (nothing there yet)
Project status:
- server is set up
- RPMs built
- not yet deployed
Open questions:
- creating the initial content set (pull from already approved RPMs containing Python packages?)
- how/where to build wheel files from upstream source packages
- whether to apply Fedora patches to uploaded files (affected by answer to previous question)