No edit summary |
No edit summary |
||
| Line 24: | Line 24: | ||
== pip configuration == | == pip configuration == | ||
<code> | <code> | ||
[global] | [global] | ||
index-url = http://localhost:3141/root/pypi/+simple/ | index-url = http://localhost:3141/root/pypi/+simple/ | ||
</code> | </code> | ||
<references/> | <references/> | ||
Revision as of 17:15, 19 March 2015
This document details realization of User Level Package Management for the Python use case.
DevPi
DevPi is a PyPI compatible server that we can use to mirror a restricted set of packages and their versions from the root PyPI server. A DevPI server can have multiple indexes -- repositories for metadata and files.
Indexes and packages
The Fedora Python DevPI server will contain several indexes, in the form of fedora/21, fedora/22, etc. for each supported Fedora release. Each index will include PyPI packages that are packaged in the relevant Fedora branch. These packages will be rebuilt as wheel with Python runtime that is used as system Python in the relevant Fedora branch.
The set of packages and their versions that are to be mirrored will be determined by a whitelist file that will be generated by scanning all the Fedora packages in the relevant Fedora branch and determining if they come from PyPI.
Since not all packages that use PyPI are named python-* and since not all python-* packages use PyPI, this would probably be best done by inspecting the Source field in spec file.
This whitelist will then be passed to DevPI using the feature described in [1].
Package versions
The Fedora indexes will mirror all version that are equal or higher compared to version of the respective package in Fedora. Indexes covering other products can have different permissivity, e.g. RSHSCL indexes could mirror only the specific version that is included in the product.
Patches
Downstream patches will not be applied to the mirrored packages. If we want to offer newer package version through our DevPI instance, we'd have to consider what to do, when the patches can no longer be automatically applied. We could either only mirror versions that are compatible with our patches, which to me seems to defeat the purpose of this whole service, to certain extend. Or we could patch versions compatible with our patches, and leave newer ones unpatched, but that seems to make it difficult to predict the behaviour of the packages.
Issue reporting
Since we will mirror package version that are not part of Fedora and may have issues, e.g. got relicensed under a lincese that in not OK for Fedora, we will have a way of reporting these issues. This could be at least partially automatized with a tool like licorice [2].
pip configuration
[global]
index-url = http://localhost:3141/root/pypi/+simple/