It should be possible to do rootless manylinux builds in containers with podman/buildah: https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/
Last I checked, rootless within rootless as you'd need for CI builds is problematic due to overlayfs within overlayfs not working. Otherwise, You *can* specify a nonroot --prefix/--installroot to install (build-dep) packages to But then you'd be building a chroot without seccomp, cgroups, namespaces On Thu, Apr 2, 2020, 9:34 PM Antonio Cavallo <antonio.cavallo...@gmail.com> wrote: > 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/HORCHKNRX3FVXUNGWT6MLNZVTFALBTHR/ Code of Conduct: http://python.org/psf/codeofconduct/
