Wenn Sie ein Han sind, möchten Sie Python Pip verwenden, um ein vorgefertigtes Rad zu installieren, das C ++ - Module unter Windows, MacOS und Linux enthält!
Lass es uns mit Cibuildwheel machen!
https://github.com/joerick/cibuildwheel
Es ist ein Skript, das in verschiedenen Umgebungen und Python-Versionen erstellt wird. Es ist großartig. Sie können dies in Ihr eigenes Projekt-CI (Travis, GitHub-Aktionen usw.) integrieren.
Es ist ein wenig schwer zu verstehen,
$ python3 -m cibuildwheel --output-dir wheelhouse
Durch Ausführen wird für jede Python-Versionsumgebung das Äquivalent python setup.py bdist_wheel erstellt und ausgeführt.
(Verwenden Sie Docker für Linux und MacOS).
In cibuildwheel werden Linux und macOS im Docker-Container ausgeführt. Wenn Sie also einen CI-Build mit Travis usw. durchführen, muss im Docker-Container so etwas wie "git submodule update" ausgeführt werden.
Sie können einige in den Umgebungsvariablen von cibuildwheel festlegen.
https://cibuildwheel.readthedocs.io/en/latest/options/
Beachten Sie, dass Sie ein Paket in Linux-Binärdatei auf PyPI hochladen https://qiita.com/syoyo/items/6185380b8d9950b25561
Bitte beziehen Sie sich auf
Mit der Azure-Pipeline scheint die Upload-Automatisierung nach dem Erstellen mit Bindfaden usw. derzeit problematisch zu sein. Ist die Einstellung von vispy jedoch hilfreich?
https://github.com/vispy/vispy/blob/master/azure-pipelines.yml
Derzeit wurde eine Vorlage vorgeschlagen, es scheint jedoch einige Einschränkungen zu geben.
https://github.com/joerick/cibuildwheel/issues/229
Ich habe tatsächlich versucht, es mit tinyobjloader zu verwenden, aber die Online-Dokumentation war schwer zu verstehen und fühlte sich problematischer an als Travis. (Es wäre schön, wenn die yaml-Beschreibung mit einem Online-Editor syntaktisch überprüft werden könnte.)
Wenn Sie Travis verwenden können, empfehlen wir die Verwendung von Travis (oder Github-Aktionen).
$ (Build.ArtifactStagingDirectory) ist der Staging-Ordner - task: PublishBuildArtifacts@1
inputs:
path: $(Build.ArtifactStagingDirectory)
artifactName: tinyobjDeployWindows
Beim Bereitstellen (Hochladen auf z. B. PyPI)
Überprüfen Sie zunächst, ob die abhängige Aufgabe abgeschlossen ist (abhängigeOn) und ob es sich um ein Tag-Commit handelt.
- job: deployPyPI
# Based on vispy: https://github.com/vispy/vispy/blob/master/azure-pipelines.yml
pool: {vmImage: 'Ubuntu-16.04'}
condition: and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/tags/v'))
dependsOn:
- linux
- macos
- windows
Verwenden Sie dann "DownloadBuildArtifacts", um die Jobartefakte (tatsächlich Ordner) herunterzuladen.
- task: DownloadBuildArtifacts@0
inputs:
artifactName: 'tinyobjDeployWindows'
downloadPath: $(Pipeline.Workspace)
Zu diesem Zeitpunkt wird ein Ordner mit "artefaktname" ("$ (Pipeline.Workspace) / tinyobjDepoloyWinwdows") erstellt und der Build darin abgelegt. Zum Debuggen scheint es gut, es mit ls usw. in das Protokoll auszugeben, damit Sie es überprüfen können.
Dann mit Schnur veröffentlichen und fertig!
# Publish to PyPI through twine
- bash: |
cd $(Pipeline.Workspace)
find .
python -m pip install --upgrade pip
pip install twine
echo tinyobjDeployLinux/python/dist/*
echo tinyobjDeployLinux/python/wheelhouse/* tinyobjDeployMacOS/python/wheelhouse/* tinyobjDeployWindows/python/wheelhouse/*
twine upload -u "__token__" --skip-existing tinyobjDeployLinux/python/dist/* tinyobjDeployLinux/python/wheelhouse/* tinyobjDeployMacOS/python/wheelhouse/* tinyobjDeployWindows/python/wheelhouse/*
env:
TWINE_PASSWORD: $(pypiToken2)
Registrieren Sie für das TWINE-Kennwort (geheimes Token) das geheime Token mit Variable auf der Azure Pipeline-Website unter dem Namen "pypiToken2".
Warten Sie jedes Mal, wenn ich den Build drücke und auslöse, etwa 10 Minuten, beheben Sie ihn, wenn ein Fehler auftritt, und hängen Sie das Tag erneut an. Das Drücken ist problematisch. Daher möchte ich eine Umgebung, in der ich es ausprobieren kann.
Twine token
Die Azure-Pipeline verfügt auch über eine Funktion für geheime Variablen, die geheime Twine-Token (PyPi) verarbeiten kann. Sie können diese also verwenden.
https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#secret-variables
Die Secret-Variable wird über die Umgebungsvariable im Build-Skript angegeben.
PublishPipelineArtifact gibt nur Protokolle aus, die nicht einmal die Fehlermeldung Ein oder mehrere Fehler sind aufgetreten (es wird kein Fehlergrund angezeigt) und funktionieren nicht.
https://stackoverflow.com/questions/58841733/how-to-debug-azure-devops-task-publishpipelineartifact-when-one-or-more-errors-o
Verwenden Sie "PublishBuildArtifacts".
cibuildwheel, pypi upload,
pytinyexr (PyEXR) verwendet Travis.
https://github.com/syoyo/PyEXR
tinyobjloader verwendet die Azure-Pipeline.
https://github.com/tinyobjloader/tinyobjloader/blob/master/azure-pipelines.yml
Py2.7(or pypy) + Windows + pybind11
Zumindest pypy verursacht einen Build-Fehler. Fügen Sie daher pp27-win32 und pp36-win32 in CIBW_SKIP ein und erstellen Sie nicht.
(Benutzt jemand Pypy?)
Außerdem ist Python2.7 + C ++ 11 grundsätzlich veraltet.
https://cibuildwheel.readthedocs.io/en/stable/cpp_standards/
Sofern Sie keinen starken Grund haben, py27 zu verwenden, sollten Sie Python 2.7 nicht unterstützen.
Recommended Posts