On Wed, Nov 24, 2021 at 10:30 AM Konrad Weihmann <[email protected]> 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 > > Thank you for the list, this helps immensely. Perhaps we should start a Wiki to capture these. > 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. > > This good news is typing_extensions uses flit_core, so there will be a path soon. This gives me more justification to support flit in oe-core (probably a flit.bbclass too?) > 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. > > Seems that way. But I am trying to move to a pure pyproject.toml (and wheels) solution just in case. > > > > > > 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 > > I am certainly happy to try other solutions. This workaround was what I could get done in a reasonable time frame to support oe-core upgrades. > > > > 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. > > > > 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 (#1365): https://lists.openembedded.org/g/openembedded-architecture/message/1365 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]] -=-=-=-=-=-=-=-=-=-=-=-
