Packaging Question
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Fonctionnalité
- Clarté
- À clarifier
- Activité
- À l'abandon
- Domaine
- build-system, release
Piste de recherche
Commencez par la dépendance d’objet partagé générée indiquée dans l’issue et par la question du packaging de pip/PyPI. Déterminez une approche de packaging Linux prise en charge pour plusieurs versions de Python et la manière dont Boost.Python doit être géré ; le travail est terminé lorsque l’issue comporte une voie de packaging concrète et que ses exigences de compatibilité sont claires.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Hi all,
I am using a library built on Boost.Python as a dependency for some of my other projects. This library (https://github.com/ompl/ompl) requires building from source and is always linked to the system Python. I would like to make it installable via pip and distribute it on PyPi. My biggest question around this is how to handle Boost.Python. When I look at the generated shared object files, they are linked to a Python-version-specific version of Boost. Namely, I see
libboost_python38.so.1.71.0 => /usr/lib/x86_64-linux-gnu/libboost_python38.so.1.71.0 (0x00007f9d6d9b7000)
I'm wondering what is the best practice for distributing a pre-built package like this? Should I statically link to a particular version of Boost.Python? Assuming I only handle Linux support to start, I don't mind asking them to use apt to install Boost. But, I'd like to enable support across multiple Python versions. If, for example, they are running Ubuntu 20.04, which has system Python version of 3.8, libboost-python-dev seems to install the 3.8-specific version. Would I have to include the entire boost source code and build from scratch when they run pip install?
I'd love to learn by example, but I haven't been able to find any PyPi-distributed packages that use Boost.Python. Can anyone point me to one?
Thanks a lot for your help!
- Langage dominant
- C++
- Étoiles
- 537
- Forks
- 223
- Merge moyen
- 11 h 22 min
- PR mergées (30 j)
- 2
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de boostorg/python
-
numpy::from_data calls vector::front and crashes (or has UB) when called with a scalar object Ouverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 84/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
-
BoostDetectToolset-1.90.0.cmake file not found in an include() call in boost_python-config.cmake Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 48/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
Toutes les issues de boostorg/python
Issues similaires
-
ai_reviewed
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
ydb-platform/ydb#53869 · 3 commentaires ·
-
bug cert blocker needs triage
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
project-chip/connectedhomeip#74373 ·
-
[request] tracy/0.14.1 Ouverteupstream update
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
conan-io/conan-center-index#31035 ·
-
Bug
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
documentation
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
vllm-project/vllm-ascend#17329 ·