On Wed, Nov 24, 2021 at 10:43 AM Konrad Weihmann <[email protected]> wrote:
> > > On 24.11.21 19:30, Konrad Weihmann wrote: > > On 24.11.21 18:44, Tim Orling wrote: > >> > >> > >> On Tue, Nov 23, 2021 at 9:40 AM Konrad Weihmann <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Hi all, > >> > >> recently more and more python module (preferably downloaded from > >> pypi) > >> do not contain a setup.py anymore. > >> > >> > >> Can you list some examples, so we can start a todo list? I have come > >> across one or two, but it is difficult to search for them. It would > >> really help me to have some test cases. (I have a similar issue with > >> pyypi packages with Rust extensions... not easy to find them). > > > > In the things that I maintain I so far came across > > > > javaproperties -> using setup.cfg > > jsonschema -> using setup.cfg > > tomli -> same > > typing_extensions -> using just pyproject.toml > > > > for the first ones I started working on a small conversion util that > > will create a "fake" setup.py using the input from setup.cfg (there is a > > well documented tranlation table available directly from pypa). > > Results have been quite good so far - so we could at least cover most of > > the projects that made the transition away from setup.py. > > > > For the last one, I'm currently out of ideas, but to patch in a crafted > > setup.py. > > > > From what I understood in the pypa discussions pyproject.toml will > > likely be the preferred choice. > > support for setup.cfg probably will be declared outdated, but likely > > support will remain indefinitely. > > > >> > >> > >> I remember there were attempts to use https://github.com/pypa/build > >> <https://github.com/pypa/build> > >> instead, but to me it always boiled down to a huge chicken and egg > >> issue, as the tool itself has quite a large dependency list [1]. > >> > >> I have been working with python3-pep517, python3-build, python3-flit > >> recipes, but they are not ready yet. More below. > > > > Thanks for the update - so I haven't missed out on any so far > > > >> > >> Lately I've seen rather hackish approaches to the issue [2]. > >> Is this the way we need to go? > >> > >> > >> As Denys said, this was ONLY because of the circular dependency issue. > >> Until upstream Python has a TOML parser in CPython, we need this > >> setup.cfg workaround for python3-tomli specifically. > > > > I think my new util experiment will solve that > > > >> > >> If so, wouldn't it make s-ense to create some bb-helper-class for it > >> (I'm > >> willing to give it a try). > >> > >> What we really need is a bbclass that knows how to build and install > >> wheels. We will need to pass the --no-dependencies argument to > >> pip-native. We need to make absolutely certain that pip is not > >> downloading and installing anything for us. The concept is that the > >> contents from bdist_wheel (the "wheel") would be installed into the > >> sysroot and then the resulting files would be what we actually package > >> in ipk/deb/rpm. I haven't come up with a brilliant name for the new > >> bbclass, but perhaps pypa-wheels? > > > > Wheels are definitely not the right choice IMO - and looking at the > > different directions the discussions at pypa go, I think we are still > > far from having an accepted and stable packaging solution for python > > code (that comes without the very same dependency loop such as > toml/tomli) > > > >> > >> NOTE: I have zero intention of supporting installation of third-party > >> wheels. Only wheels we have built. > >> > >> I have begun some local sandbox on this, but again, not ready yet. > >> Between the Phosh and Kernel-Lab presentations for the Yocto Summit I > >> have been very backlogged. One promising package is flit, it has a > >> bootstrapping module in flit_core that we can use to build the > >> bdist_wheel with very little else. That can then be used to build > >> python3-flit-native, which could then be used for other packages that > >> use flit in their pyproject.toml. > >> > >> Did anyone had a in-depth talk with pypa upstream about that and > what > >> was the outcome of that discussion? > >> > >> You can find various conversations in GitHub issues or PEP > >> discussions, but ultimately it comes down to: > >> (1) setup.py might be provided on an interim basis, but is deprecated > >> (2) egg-info is deprecated in favor of wheels > >> (3) setup.py is deprecated in favor of pyproject.toml (and also > >> sometimes setup.cfg, but this is inconsistent) > >> (3) packages are installed with pip > > > > Thanks, will look into it in the next days > > > >> > >> We cannot fight this change, which has been a long time coming > >> already. We need to adapt to it. > > > > So far unfortunately (also judging from the pypa discussions) I don't > > see many options, but to remain on the outdated approach in core and > > apply some crafted or patched fallback setup.pys. > > > >> > >> We have a "languages" topic for the OEDVM, and python is amongst the > >> things affected. > > As of now I think the most viable solution would be if setuptools and > all that toml parsing stuff would be moved into python-core, but I have > no idea if that is somehow on the python upstream's roadmap. > > I agree. The argument against is that having things outside python-core (CPython) allows for a more nimble, agile development process. But this feels like it assumes that there are infinite developers with infinite time to fix infinite packages. On the other hand, we ourselves are making breaking changes to oe-core so that we can move forward. I can understand both sides of the argument. My plan is to adapt to upstream pypa. >> > >> Cheers, > >> > >> --Tim > >> > >> Regards > >> Konrad > >> > >> [1] https://github.com/pypa/build/blob/main/setup.cfg > >> <https://github.com/pypa/build/blob/main/setup.cfg> > >> [2] > >> > >> > https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/python?id=6cc9954c6bac9e3c19b2b0f26a69b629a8ee7273 > >> > >> > >> < > https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/python?id=6cc9954c6bac9e3c19b2b0f26a69b629a8ee7273> > > >> > >> > >> > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1366): https://lists.openembedded.org/g/openembedded-architecture/message/1366 Mute This Topic: https://lists.openembedded.org/mt/87264004/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
