Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • abuild abuild
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 64
    • Issues 64
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 39
    • Merge requests 39
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • alpinealpine
  • abuildabuild
  • Merge requests
  • !24

Add support for creating pyX providers

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Leo requested to merge Leo/abuild:py-providers into master Feb 12, 2020
  • Overview 31
  • Commits 2
  • Pipelines 0
  • Changes 3

Add support for creating pyX providers

Now all python packages that install python modules under /usr/lib/pythonX.Y/site-packages will have a provider that indicates their MAJOR version, the X in the path.

pyX maps to the MAJOR version of the package, its objective is to allow users to quickly install a python module without having to search around for the correct package, doing apk add py3:foo will install whatever packages provides the foo module.

The directories checked only go one level deep, so '/usr/lib/python3.8/site-packages/date' will generate py3:date=$pkgver-r$pkgrel.

files ending with .py also count and are added with their .py prefix stripped away. so '/usr/lib/python3.8/site-packages/six.py' will generate py3:six=$pkgver-r$pkgrel.

The reason for doing this is the same as creating pc:, so: and cmd:, it is more reliable and robust to depened on what we known of what the package provides than to try to guess via the pkgname.

Note that this is not perfect but is a trade-off, this will not protect against installed the wrong MINOR version of the module, it is entirely possible to install py3:foo but get a foo in /usr/lib/python3.7 while one is using /usr/lib/python3.8, this was a concious decision made to avoid annoying users with gratiutious breaking messages.

Edited Oct 31, 2020 by Leo
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: py-providers