Re: Moving from appdirs to platformdirs
+1 در ۲۱ ژوئن ۲۰۲۳ ۱۲:۴۱:۵۲ (UTC)، Scott Kitterman نوشت: >It would be nice if we could reduce/eliminate use of appdirs during the Trixie >development cycle. It's unmaintained and superseded by platformdirs. As far >as I can tell, platformdirs is API compatible with appdirs, except the import >path is different. > >As a result, switching does need some changes in the upstream code. This point >in the development cycle is a good time to work with upstream to have them >make the change upstream. I did this this week with xml2rfc, it was pretty >painless, and will be included in the next release. As we approach the >freeze, then I think we should shift to working on Debian specific changes. > >There's a list below of the affected packages (all of them, not just Debian >Python packages). I don't intend to do a MBF now, but may do so later in the >year (when hopefully the list will be shorter). > >Scott K > >Reverse-Testsuite-Triggers >== >* mu-editor >* pyspectral >* python-ironicclient >* python-mbed-ls >* python-openstacksdk >* satpy > >Reverse-Build-Depends >= >* datalad >* defcon >* genx >* git-phab >* glean-parser >* intake >* mu-editor >* nuitka >* nvchecker >* ofxstatement >* ofxstatement-plugins >* openlp >* openmotor >* pako >* platformdirs >* plover >* pyspectral >* python-cobra >* python-datacache >* python-easydev >* python-fissix >* python-fs >* python-lsp-rope >* python-mbed-ls >* python-requests-cache >* python-rply >* python-ulmo >* pytoolconfig >* rope >* satpy >* snakemake >* telegram-send >* xml2rfc >* yowsup > >Reverse-Build-Depends-Indep >=== >* pydoctor >* python-ironicclient >* python-miio >* python-openstacksdk >* python-os-faults >* python-smstrade >* subliminal >* urlwatch > >Reverse-Recommends >== >* python3-profitbricks > >Reverse-Depends >=== >* crossgrader >* git-phab >* glean-parser >* mu-editor >* nuitka >* nvchecker >* ofxstatement >* ofxstatement-plugins >* openlp >* openmotor >* plover >* printrun-common >* pronsole >* ptpython >* pydoctor >* python3-cobra >* python3-datacache >* python3-datalad >* python3-easydev >* python3-etesync >* python3-fissix >* python3-fs >* python3-genx >* python3-intake >* python3-ironicclient >* python3-libpysal >* python3-mbed-ls >* python3-miio >* python3-openstacksdk >* python3-os-faults >* python3-pako >* python3-pantalaimon >* python3-pycuda >* python3-pyopencl >* python3-pyspectral >* python3-pytools >* python3-requests-cache >* python3-rply >* python3-satpy >* python3-smstrade >* python3-subliminal >* python3-ulmo >* python3-yowsup >* snakemake >* sqlfluff >* telegram-send >* urlwatch >* xml2rfc
Re: Siging up for the Contribution on Python Packaging for Debian
Hey, File an ITP bug for it against wnpp pseudo package and start to package it on https://mentors.debian.org Ask here after you filed the RFS. Sincerely در ۲۵ مهٔ ۲۰۲۳ ۱۲:۱۹:۰۰ (UTC)، TopologicRose نوشت: >Hi, >want to contribute a Python package which called pyvis >(https://pyvis.readthedocs.io/en/latest/index.html) for APT. >A friend of mine works with it and wants it as a Debian package instead of pip. > >Best regards, >Thanh-Viet Nguyen
Adopting python-fire
Dear team. I adopted python-fire package which was orphaned before since my own package is depending on it. I uploaded it on mentors and gitlab. So I am looking for a sponsor for it: * Package name : python-fire Version : 0.5.0-2] * URL : https://github.com/google/python-fire * License : Apache-2.0 * Vcs : https://salsa.debian.org/python-team/packages/python-fire Section : python The source builds the following binary packages: python3-fire - automatically generate CLIs from absolutely any Python object To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-fire/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-fire/python-fire_0.5.0-2.dsc Changes since the last upload: python-fire (0.5.0-2) unstable; urgency=medium . * Adopt orphaned package as Debian Python team. (Closes: #1013206) * Bump Standards-version to 4.6.2. * Update d/copyright * Update d/watch Regards, -- Danial Behzadi
Re: #!/usr/bin/python3 vs virtualenv
You just want to install sphinx via pip in the virtual environment too. Each venv should be atomic and isolated which means not depended to system packages.
Re: Python 3.10 in bookworm
Does it worth trying to package pyenv for Debian? Ain't it against any rules?
Re: How do you create entry-points for Python applications?
> The only package I maintain that I can think of at the moment with > entrypoints and project.toml is too complicated to be a good example. That shouldn't be so much different from setup.py projects and there are plenty of them in archive.
Re: How do you create entry-points for Python applications?
AFAIK Debian helper for Python handles this در 18 دسامبر 2022 19:18:44 (UTC)، c.bu...@posteo.jp نوشت: >Hello, >a python application isn't a binary but a script. So to invoke such an >application there need to be a shell script somewhere in PATH that invoke that >script via python3 interpreter. Imagine an application with a GUI (qt, >tikinter, gtk, ...). > >On the upstream site modern python projects using pyproject.toml (only), some >use setup.cfg. >There you can define "entry points" and the "pip" installer does generate a >shell script based on that information and place it in PATH. >That is a nice mechanism when installing via pip. > >On your site as distro maintainers. How do you take care of then when creating >deb files? >When a project do follow modern python packaging standards using >pyproject.toml/setup.cfg and doesn't offer any other explict start shell >script. Do you use that pip mechanic for the deb package? >Or how do you create your shell scripts? > >I don't have an real world example of a python application for that. > >I only have an example of a project (backintime) that don't use >pyproject.toml/setup.cfg and offer its own shell script. I'm part of the new >maintainer team and we will evolve the project to current python packaging >standards; which means using pyproject.toml. >
