python-devel June 2020

python-devel@lists.fedoraproject.org

17 participants
23 discussions

Re: [Fedora-packaging] Package tests?
by Miro Hrončok 09 Jun '20

09 Jun '20

On 09. 06. 20 21:49, Miroslav Suchý wrote: > Hi. > On my system: > du -ch /usr/lib/python3.8/site-packages/*/tests/ > 18 MB in total > > I did not see anything in Guidelines about packaging tests. Do we really need them in final package? It depends on the package, but in majority of the cases, we don't. > Are there any > objection to propose in Guidelines something like: > > %exclude %{python3_sitelib}/YOUR-MODULE/tests I am all in to say the tests SHOULD NOT be packaged (assuming the package works without them) and SHOULD either be removed or packaged into a -tests subpackage. However, somebody might argue %exclude is not the bast tool for the job: https://github.com/rpm-software-management/rpm/issues/994#issuecomment-5765… Side note: rpmlint upstream wants to warn about exactly this: https://github.com/rpm-software-management/rpmlint/pull/430 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Re: Python packaging workflow future (setup.py install removal and PEP517)
by Filipe Laíns 06 Jun '20

06 Jun '20

On Fri, 2020-06-05 at 22:49 +0200, Miro Hrončok wrote: > On 05. 06. 20 22:30, Filipe Laíns wrote: > > Hi, > > Hey Filipe. > > For Fedora related Python packaging topics, would you be OK to use a > public > mailing list? > > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproj… Sure :) > > I am querying you a your current python packaging workflow. How do > > you > > handle the installation of python packages? setuptools, pip, > > other...? > > For the old packages, we still very much use python setup.py install. > > For the new, we have provisional system that uses PEP 517/518. > > https://src.fedoraproject.org/rpms/pyproject-rpm-macros > > We have a draft of new Python packaging guidelines that use this: > > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproj… Oh okay, that seems reasonable. > > In Arch Linux we use setuptools (setup.py build && setup.py > > install). > > For PEP517 we generally use dephell to generate a setup.py script, > > it > > works most of the time but it's still an hack. > > > > Unfortunately, setup.py install will be removed soon (see [1]), > > which > > breaks our workflow. My proposed workflow alternative is to build > > wheels (via PEP517 or setuptools directly) and install them. > > I will read that ticket later, it is very long :/ > > > We don't think pip is a viable option for this because it requires > > bootstrapping a big number of dependencies. Packaging a vendored > > version of pip goes against our guidelines. > > We went the "lazy" way and our pip bundles the vendored deps. I am > not very > happy about it, but it works. Our guidelines discourage it, but it is > possible. I see. I guess if we had absolutely no other option, that would be possible too, but we really really don't want to. > > I have been working on some the tooling that should be able to fit > > our > > needs: python-build[2] and python-install[3]. I have also been in > > contact with a few PyPA members who have shown interest in having > > such > > tools. > > Nice. See also https://github.com/pradyunsg/installer/issues/1 Yeah, I have been participating in the discussions. > > So, I would like to ask you if you are facing a similar problem? If > > so, > > I would like to get your opinion on this new tooling. Does it fix > > your > > problem? Do you have any reservations about this? Are there any > > special > > use-cases you would like to handle? > > Even if we create the entirely new packaging experience with PEP > 517/518 based > macros, we have thousands of exciting packages that rely on python > setup.py > install. If that gets removed, it will be very painful. If it is > "just" > unsupported, we might be OK. Right now it is only unsupported, but the maintainers said it will be removed. Can't you just adjust the macro definition? In the build step, instead of setup.py install you run setup.py bdist_wheel, and then in the install step you install the wheel. The new workflow should be compatible, the different would be that instead of installing directly, you build a wheel and then install the wheel. > > [1] https://github.com/pypa/setuptools/issues/2088 > > [2] https://github.com/FFY00/python-build > > [3] https://github.com/FFY00/python-install Cheers, Filipe Laíns -- Filipe Laíns

1 0

Freecad and Python 3.9 help needed
by Richard Shaw 03 Jun '20

03 Jun '20

I'm trying to rebuild FreeCAD but I've run into the following and I don't know how to fix it. --- In file included from /builddir/build/BUILD/FreeCAD-0.18.4/src/App/ExtensionPyImp.cpp:34: /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/ExtensionPy.cpp:76:1: warning: missing initializer for member '_typeobject::tp_vectorcall' [-Wmissing-field-initializers] 76 | }; | ^ In file included from /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/PropertyContainerPy.h:7, from /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/DocumentPy.h:7, from /builddir/build/BUILD/FreeCAD-0.18.4/src/App/Expression.cpp:32: /builddir/build/BUILD/FreeCAD-0.18.4/build/src/Base/PersistencePy.h:67:9: error: 'Int' in namespace 'Py' does not name a type 67 | Py::Int getMemSize(void) const; | ^~~ In file included from /builddir/build/BUILD/FreeCAD-0.18.4/src/App/Expression.cpp:32: /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/DocumentPy.h:179:9: error: 'Int' in namespace 'Py' does not name a type 179 | Py::Int getUndoMode(void) const; | ^~~ /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/DocumentPy.h:183:26: error: 'Py::Int' has not been declared 183 | void setUndoMode(Py::Int arg); | ^~~ /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/DocumentPy.h:187:9: error: 'Int' in namespace 'Py' does not name a type 187 | Py::Int getUndoRedoMemSize(void) const; | ^~~ /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/DocumentPy.h:194:9: error: 'Int' in namespace 'Py' does not name a type 194 | Py::Int getUndoCount(void) const; | ^~~ /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/DocumentPy.h:201:9: error: 'Int' in namespace 'Py' does not name a type 201 | Py::Int getRedoCount(void) const; | ^~~ In file included from /builddir/build/BUILD/FreeCAD-0.18.4/src/App/PropertyContainerPyImp.cpp:40: /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/PropertyContainerPy.cpp:76:1: warning: missing initializer for member '_typeobject::tp_vectorcall' [-Wmissing-field-initializers] 76 | }; | ^ In file included from /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/PropertyContainerPy.h:7, from /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/ExtensionContainerPy.h:7, from /builddir/build/BUILD/FreeCAD-0.18.4/build/src/App/DocumentObjectPy.h:7, from /builddir/build/BUILD/FreeCAD-0.18.4/src/App/FeaturePython.cpp:35: /builddir/build/BUILD/FreeCAD-0.18.4/build/src/Base/PersistencePy.h:67:9: error: 'Int' in namespace 'Py' does not name a type 67 | Py::Int getMemSize(void) const; | ^~~ --- Full log here: https://kojipkgs.fedoraproject.org//work/tasks/7099/45227099/build.log Thanks, Richard

5 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel June 2020