No, I think you might be doing it wrong. FWIW, I haven't needed to compile CPython in 10 years (iot to build something other than CPython) because official builds of Conda, DEB, RPM, or Docker containers are generally sufficient.
Are you familiar with the manylinux specs? I should've thought to mention that you can build maximally-portable packages with the manylinux docker containers as your base image: https://github.com/pypa/manylinux https://github.com/pypa/manylinux/blob/master/README.rst#docker-images https://pypi.org/project/auditwheel/ : > auditwheel is a command line tool to facilitate the creation of Python wheel packages for Linux (containing pre-compiled binary extensions) that are compatible with a wide variety of Linux distributions, consistent with the PEP 513 manylinux1, PEP 571 manylinux2010 and PEP 599 manylinux2014 platform tags. On Thu, Apr 2, 2020, 8:48 PM Antonio Cavallo <antonio.cavallo...@gmail.com> wrote: > To distribute python binaries (interpreter + extensions) on linux one need > to compile it using the lowest common denominator (eg. some linux distro > really old, like rhel6). > Later when a user need to build an extension that might not be possible > (because the running host might not have a compatible compiler). > > So I think a good idea would be starting from the toolchain (eg. in my > case I use gcc 9.2.x). > > These days if I need to use java/node/etc. I won't go through the > re-building the interpreter/jvm. Does that make sense? > > > > > On Thu, 2 Apr 2020 at 20:39, Wes Turner <wes.tur...@gmail.com> wrote: > >> So you want to import from / call into what would be in $prefix/lib & >> $prefix/include? >> >> How is the SDK archive use case different from the package archive use >> case? >> >> On Thu, Apr 2, 2020, 8:32 PM Antonio Cavallo < >> antonio.cavallo...@gmail.com> wrote: >> >>> Yes, I'm aware of those.. providing an application wouldn't be what I >>> have in mind. >>> >>> The point would be providing a python sdk, similar to what >>> node/java/.net provide. something it would possible to build upon. >>> Those are distributed as stand alone "zip" to the general public. >>> >>> >>> >>> On Thu, 2 Apr 2020 at 20:15, Wes Turner <wes.tur...@gmail.com> wrote: >>> >>>> Would e.g. pyinstaller or constructor solve the problem? >>>> >>>> https://pyinstaller.readthedocs.io/en/stable/ >>>> >>>> > PyInstaller bundles a Python application and all its dependencies >>>> into a single package. The user can run the packaged app without installing >>>> a Python interpreter or any modules. PyInstaller supports Python 2.7 and >>>> Python 3.5+, and correctly bundles the major Python packages such as numpy, >>>> PyQt, Django, wxPython, and others. >>>> > >>>> > PyInstaller is tested against Windows, Mac OS X, and GNU/Linux. >>>> However, it is not a cross-compiler: to make a Windows app you run >>>> PyInstaller in Windows; to make a GNU/Linux app you run it in GNU/Linux, >>>> etc. PyInstaller has been used successfully with AIX, Solaris, FreeBSD and >>>> OpenBSD but testing against them is not part of our continuous integration >>>> tests. >>>> >>>> https://github.com/conda/constructor : >>>> >>>> > Constructor is a tool which allows constructing an installer for a >>>> collection of conda packages. It solves needed packages using user-provided >>>> specifications, and bundles those packages. It can currently create 3 kinds >>>> of installers, which are best thought of as delivery vehicles for the >>>> bundled packages. There are shell installers, MacOS .pkg installers, and >>>> Windows .exe installers. Each of these will create an environment on the >>>> end user's system that contains the specs you provided, along with any >>>> necessary dependencies. These installers are similar to the Anaconda and >>>> Miniconda installers, and indeed constructor is used to create those >>>> installers. >>>> >>>> One advantage of ~ 'dynamic linking' / not shipping the python binary >>>> is that you then don't need to sign and distribute new releases for every >>>> minor release of cpython >>>> >>>> On Thu, Apr 2, 2020, 8:09 PM Antonio Cavallo < >>>> antonio.cavallo...@gmail.com> wrote: >>>> >>>>> Not quite, my hope is to have a python tarball similar to the "Windows >>>>> x86 embeddable zip file" but for linux. >>>>> Similar to miniconda but for plain python, or sort of python "sdk", if >>>>> that makes sense. >>>>> >>>>> Thanks >>>>> >>>>> PS. I didn't know about the core workflow, thanks >>>>> >>>>> >>>>> On Thu, 2 Apr 2020 at 19:55, Wes Turner <wes.tur...@gmail.com> wrote: >>>>> >>>>>> https://devguide.python.org/buildbots/ >>>>>> >>>>>> These run in Docker containers: >>>>>> - https://github.com/python/cpython/blob/master/.travis.yml >>>>>> - >>>>>> https://github.com/conda-forge/python-feedstock/blob/master/recipe/build.sh >>>>>> >>>>>> These are all of the current builds; are you proposing another? >>>>>> >>>>>> https://github.com/python/buildmaster-config/blob/master/master/custom/builders.py >>>>>> >>>>>> https://github.com/python/buildmaster-config/blob/master/worker_example.Dockerfile >>>>>> >>>>>> https://github.com/buildbot/buildbot_travis : >>>>>> >>>>>> > Basically we provide a compatibility shim in buildbot that allows >>>>>> it to consume a .travis.yml file. >>>>>> > >>>>>> > buildbot_travis does however not support the full .travis.yml >>>>>> format. >>>>>> >>>>>> https://github.com/python/core-workflow/issues >>>>>> >>>>>> >>>>>> On Thu, Apr 2, 2020, 6:36 PM Antonio Cavallo < >>>>>> antonio.cavallo...@gmail.com> wrote: >>>>>> >>>>>>> Hi >>>>>>> is there any interest (or anyone has done it before), building the >>>>>>> python interpreter using docker? >>>>>>> >>>>>>> The basic idea is building the toolchain (gcc) and on top of that >>>>>>> the python interpreter. On mac/linux it can build natively, but it can >>>>>>> use >>>>>>> docker to target linux from mac/windows. >>>>>>> >>>>>>> Thanks >>>>>>> _______________________________________________ >>>>>>> Python-ideas mailing list -- python-ideas@python.org >>>>>>> To unsubscribe send an email to python-ideas-le...@python.org >>>>>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>>>>>> Message archived at >>>>>>> https://mail.python.org/archives/list/python-ideas@python.org/message/DX7WNXJGFZJZSSVV5KG54TMW3AFTELET/ >>>>>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>>>>> >>>>>>
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/B3OL6TKWCAACL3JP6H4BSSPGH2S4HIJ3/ Code of Conduct: http://python.org/psf/codeofconduct/
