Probably, but I'm still convinced a sdk would be nice. Yes, I'm aware of manylinux. DEB/RP suffer from the fact that need to be "root" installed and manylinux needs docker to be used, so same issue.
Thanks On Thu, 2 Apr 2020 at 20:55, Wes Turner <wes.tur...@gmail.com> wrote: > 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/456UCFWK4OFI76B6ODNYOSH7D3SGTW4U/ Code of Conduct: http://python.org/psf/codeofconduct/
