Updating Flask to 3.x?
Hi, the Flask team released Flask and the depending package Werkzeug 3.0.0 on 2023-09-30. Since Thomas Goirand did the last update of Flask to 2.2.x nearly one year ago in preparation for the Bookworm release I've talked with Thomas recently about updating Flask and depending packages again so we can get Flask 3.x into the archive. Thomas pointed out he will not have time to work on Flask 3 and some depending packages in the near future. I usual try to keep an eye on some Flask related packages as we use them on my day job. A few of them have now RC issues and are already kicked out of testing. Solving these bug reports are now mostly depending on a newer Flask version or at least it would be more useful to move over to a recent Flask version. Given we are now short before the X-mas days and I will have some more time to look at some packages I'm willing to push things further. I've started on Flask and werkzeug packages yesterday and basically there are no big issues to get these packages updated. If no objections are raised I intend to upload recent versions of python-flask and python-werkzeug to experimental next week. Once happen we will see through https://qa.debian.org/excuses.php?experimental=1&package=python-werkzeug https://qa.debian.org/excuses.php?experimental=1&package=flask which packages would prevent a migration later due build or test failures. Following a simple list of reverse deps for the resulting binary packages. Any help, suggestion or useful hint in maintaining this Flask update is really appreciated! @Thomas Do you agree on my plan? Or do you have reasons to wait a bit more with uploading Flask and Werkzeug to experimental? $ LANG= apt rdepends python3-flask python3-werkzeug python3-flask Reverse Depends: Depends: python3-flask-api (>= 0.12.3) Depends: mu-editor (>= 1.0.2) Depends: python3-etesync-dav Depends: voltron Depends: supysonic (>= 0.11) Recommends: snakemake Depends: python3-sahara (>= 2.1.2) Depends: recon-ng Suggests: python3-livereload Depends: python3-flask-sockets Depends: python3-flask-seeder (>= 1.0.2) Depends: python3-flask-marshmallow Depends: python3-python-flask-jwt-extended (>= 2.0) Depends: python3-python-flask-jwt-extended (<< 4.0) Depends: python3-flask-httpauth Depends: python3-flask-cors (>= 0.9) Depends: python3-flasgger (>= 0.10) Depends: python3-pytest-flask Depends: python3-trove (>= 2.2.3) Depends: python-openslide-examples Depends: openlp Depends: onionshare-cli (<< 3.0.0) Depends: onionshare-cli (>= 2.0.0) Depends: mkchromecast Depends: mitmproxy (>= 1.1.1) Depends: python3-locust (>= 2.0.0) Depends: lektor Depends: python3-klaus Depends: python3-keystone Depends: json-schema-test-suite Depends: python3-ironic-inspector (>= 1.1.0) Depends: python3-impacket Depends: python3-httpbin Depends: gftools Depends: python3-flaskext.wtf Depends: python3-flask-sqlalchemy (>= 2.2) Depends: python3-flask-socketio (>= 0.9) Depends: python3-flask-session Depends: python3-flask-restful (>= 0.8) Depends: python3-flask-principal Depends: python3-flask-peewee Depends: python3-flask-paranoid (>= 0.10) Depends: python3-flask-paginate Depends: python3-flask-openid (>= 0.10.1) Depends: python3-flaskext.multistatic Depends: python3-flask-mongoengine (>= 1.1.2) Depends: python3-flask-migrate (>= 0.9) Depends: python3-flask-mail Depends: python3-flask-login (>= 1.0.4) Depends: python3-flask-limiter (>= 2) Depends: python3-flask-ldapconn (>= 0.12) Depends: python3-flask-jwt-simple Depends: python3-flask-htmlmin Depends: python3-flask-flatpages (>= 0.8) Depends: python3-flask-dance (>= 2.0.3) Depends: python3-flask-compress Depends: python3-flask-caching Depends: python3-flask-bcrypt Depends: python3-flask-basicauth Depends: python3-flask-babelex Depends: python3-flask-babel (>= 2.0) Depends: python3-cloudkitty (>= 2.0.0) Recommends: python-flask-doc Suggests: dnstwist Depends: python3-designate Depends: comitup Depends: a2d Depends: ceph-iscsi Depends: python3-flask-bootstrap Depends: python3-biomaj3-user Depends: python3-biomaj3-process Depends: python3-biomaj3-download Depends: python3-biomaj3-daemon Depends: bepasty Suggests: beets python3-werkzeug Reverse Depends: Depends: python3-quart (>= 2.2.0~) Depends: python3-mediagoblin Depends: ceph-mgr-dashboard Depends: ceph-mgr Depends: python3-vitrage Depends: tryton-server Depends: tryton-modules-web-shortener Depends: tryton-modules-web-shop-vue-storefront Depends: tryton-modules-timesheet Depends: tryton-modules-marketing-automation Depends: tryton-modules-account-payment-stripe Depends: tryton-modules-account-payment-braintree Depends: python3-pytest-localserver (>= 0.10) Depends: python3-pywps Depends: python3-python-flask-jwt-extended Suggests: python3-django-extensions Depends: python3-flask (>= 2.2.2)
Why is ${python3:Depends} injecting cython3-legacy (Was: obitools: runtime dependency on cython)
Hi, I checked debian/obitools.substvars which contains python3:Depends=cython3-legacy, python3 (<< 3.12), python3 (>= 3.11~), python3-ipython, python3-sphinx, python3-virtualenv, python3-wheel, python3:any I wonder what mechanism is responsible for adding cython3-legacy to the package dependencies. This looks absolutely unmotivated to me. Is there any better way than editing debian/obitools.substvars in d/rules by adding some override_dh_gencontrol? Kind regards Andreas. -- http://fam-tille.de
Re: Why is ${python3:Depends} injecting cython3-legacy (Was: obitools: runtime dependency on cython)
Hi Andreas On Sun, 17 Dec 2023 at 18:15, Andreas Tille wrote: > Is there > any better way than editing debian/obitools.substvars in d/rules by > adding some override_dh_gencontrol? Remove the line: Cython>=0.24 from requirements.txt. Regards Graham
Re: Why is ${python3:Depends} injecting cython3-legacy (Was: obitools: runtime dependency on cython)
The worse thing is when upstreams ask you to sign a CLA to accept a PR that removes one extraneous line from requirements.txt. Is it even copyrightable ? Le dim. 17 déc. 2023 à 20:21, Graham Inggs a écrit : > > Hi Andreas > > On Sun, 17 Dec 2023 at 18:15, Andreas Tille wrote: > > Is there > > any better way than editing debian/obitools.substvars in d/rules by > > adding some override_dh_gencontrol? > > Remove the line: > > Cython>=0.24 > > from requirements.txt.
Re: Why is ${python3:Depends} injecting cython3-legacy (Was: obitools: runtime dependency on cython)
On Sun, Dec 17, 2023 at 08:38:30PM +0100, Alexandre Detiste wrote: > The worse thing is when upstreams ask you to sign a CLA to accept > a PR that removes one extraneous line from requirements.txt. > Is it even copyrightable ? Even under the more absurd European interpretations that allow copyright on various works with no minimum element of creativity, I think the answer is no, removal of a line of text is not copyrightable. So let the upstream figure it out? > Le dim. 17 déc. 2023 à 20:21, Graham Inggs a écrit : > > > > Hi Andreas > > > > On Sun, 17 Dec 2023 at 18:15, Andreas Tille wrote: > > > Is there > > > any better way than editing debian/obitools.substvars in d/rules by > > > adding some override_dh_gencontrol? > > > > Remove the line: > > > > Cython>=0.24 > > > > from requirements.txt. > -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Recommended way of installing system-wide python application and libraries
Thanks!! I'll answer to the last comment but I appreciate everyone's input! Hello again Ivan (different neighborhood :)), :))) The "modern" way of building Python libraries/applications seems to be to > use a pyproject.toml. The pyproject.toml specifies a backend build system > that knows how to build the library/application and produce a wheel. Thanks for this pointer. I didn't know about this. As far as how to do this within an existing cmake project, unfortunately, > there doesn't seem to be a clear/easy way. For now, we ended up switching to venvs. I just published a release candidate. https://github.com/NASA-SW-VnV/ikos/discussions/253 Following @salvo's comment, I'm going to try and begin the process of packaging this for debian. I suspect it may be a bit complicated because ikos is two things (a library in C++ and a set of tools in Python) under a trench coat. This is by far not my domain. If anyone is willing to lend a hand, I could definitely use any help that I can get, but I understand that folks are busy and everybody wants help. Cheers, Ivan On Thu, 7 Dec 2023 at 16:12, Scott Talbert wrote: > On Tue, 5 Dec 2023, Ivan Perez wrote: > > > Hi everyone! > > > > I'm currently trying to bring a tool we have at NASA Ames up to speed: > > https://github.com/NASA-SW-VnV/ikos > > > > IKOS is a static analyzer for C. I'm really hoping that IKOS can be > included > > in Debian in the near future. > > > > IKOS is implemented as a C++ library, and a number of python > > tools/wrappers. The tools call mains in modules defined in a python > library > > `ikos`. > > > > As of right now, our CMakeFiles attempt to install everything (by > default) > > under /opt/ikos/. > > > > I'm having lots of issues getting the python portions installed > system-wide. > > I initially upgraded distutils to setuptools, but a recent update is now > > asking that I use a venv. More details and a link to a dockerfile can be > > found here: https://github.com/NASA-SW-VnV/ikos/discussions/241. > > > > While I can hack a solution that "works" (either by making a venv under > the > > target dir or by means of break-system-packages), I'd prefer to use > > recommended practices, and also conform to the way that things are done > in > > Debian/Ubuntu. > > > > What would be the recommended way of installing IKOS system-wide in > Debian? > > Hello again Ivan (different neighborhood :)), > > The "modern" way of building Python libraries/applications seems to be to > use a pyproject.toml. The pyproject.toml specifies a backend build system > that knows how to build the library/application and produce a wheel. > > As far as how to do this within an existing cmake project, unfortunately, > there doesn't seem to be a clear/easy way. The only cmake example I can > think off of the top of my head is cvc5. It still uses setup.py though, > so not a great future-looking example (and I had to patch it to build the > Python bindings in Debian): > https://github.com/cvc5/cvc5/blob/main/src/api/python/CMakeLists.txt > > If you're open to other options for building python libraries, meson might > be something to look into. I haven't used it extensively, though. It > does seem to have better support for building Python though. > > Regards, > Scott
