Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
abuild
abuild
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 25
    • Issues 25
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 16
    • Merge Requests 16
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • alpine
  • abuildabuild
  • Merge Requests
  • !24

Open
Opened Feb 12, 2020 by Leo@LeoContributor
  • Report abuse
Report abuse

Check out, review, and merge locally

Step 1. Fetch and check out the branch for this merge request

git fetch "https://gitlab.alpinelinux.org/Leo/abuild.git" "py-providers"
git checkout -b "Leo/abuild-py-providers" FETCH_HEAD

Step 2. Review the changes locally

Step 3. Merge the branch and fix any conflicts that come up

git fetch origin
git checkout "master"
git merge --no-ff "Leo/abuild-py-providers"

Step 4. Push the result of the merge to GitLab

git push origin "master"

Note that pushing to GitLab requires write access to this repository.

Tip: You can also checkout merge requests locally by following these guidelines.

Add support for creating pyX providers

  • Overview 21
  • Commits 1
  • Changes 1

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
None
Milestone
None
Assign milestone
Time tracking
0
Labels
None
Assign labels
  • View project labels
Reference: alpine/abuild!24
Source branch: py-providers