Packaging Question
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 25/100
- Tipo de issue
- Funcionalidade
- Clareza
- Precisa de esclarecimento
- Status de atividade
- Estagnada
- Domínio
- build-system, release
Direção de pesquisa
Comece pela dependência de shared object gerada mostrada na issue e pela questão de empacotamento do pip/PyPI. Determine uma abordagem de empacotamento Linux compatível para várias versões do Python e como o Boost.Python deve ser tratado; considera-se concluído quando a issue tiver um caminho concreto de empacotamento e seus requisitos de compatibilidade estiverem claros.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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!
- Linguagem predominante
- C++
- Estrelas
- 537
- Forks
- 223
- Merge médio
- 11h 22min
- PRs com merge (30d)
- 2
Guia de contribuição
Nenhum guia de contribuição indexado para este repositório
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de boostorg/python
-
numpy::from_data calls vector::front and crashes (or has UB) when called with a scalar object Aberta
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 84/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 64/100
-
BoostDetectToolset-1.90.0.cmake file not found in an include() call in boost_python-config.cmake Aberta
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 48/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 25/100
Todas as issues de boostorg/python
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
duckdb/duckdb-wasm#2258 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
objectionary/eo-graphs#75 ·
-
Coarray integration tests carry no LABELS, so run_tests.py silently skips them under every backend Abertacoarray
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
FISCO-BCOS/FISCO-BCOS#5642 ·