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/SB5JZYLAD6UXGLSSICBUIWQRNB4R3HYF/ Code of Conduct: http://python.org/psf/codeofconduct/
