Re: dh_python for single python scripts?
Hi Philippe (2024.08.16_00:52:25_+) > > Now I do have some standalone python scripts for which it makes not > much sense to make them (Python) packages (i.e. there's no > __init__.py, etc.), yet I'd still like to have stuff like > automatically getting the right Debian package dependencies in a > Debian package. > > Is that even intended to work with dh_python? dh_python doesn't care what form your python package is in. It just looks for the metadata in .dist-info / .egg-info. So, if your package declares dependencies in in the packaging, and installs correctly with python3-build, it'll work. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: new dependencies for python-pint
On 8/16/24 08:13, Antonio Valentino wrote: Dear Thomas, Il 15/08/24 09:33, Thomas Goirand ha scritto: On 8/15/24 08:10, Antonio Valentino wrote: Il 14/08/24 22:32, Thomas Goirand ha scritto: Hi, My answer below. On 8/12/24 08:04, Antonio Valentino wrote: Il 09/08/24 21:08, Antonio Valentino ha scritto: Dear Thomas, dear all, a new version (0.24.3) of python-pint is available upstream. It introduces two additional dependencies: flexcache and flexparser. I have files two ITP bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078258 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078260 and prepared the debian packages in salsa: https://salsa.debian.org/python-team/packages/flexparser https://salsa.debian.org/python-team/packages/flexcache I uploaded both. Thanks for your contrib! Thanks you for uploading. Please do not forget to grant me upload rights as per [1] so that I can to future uploads by myself. [1] https://wiki.debian.org/DebianMaintainer#Granting_Permissions Will do when it clears the NEW queue (otherwise it wont work). Please ping me when the package does. flexcache has been accepted. Once I get upload permissions granted I will proceed with the source only upload. Unfortunately flexparser has bee rejected due to incomplete d/copyright file. I'm sorry for that. I have now fixed it in git and I kindly ask you to review/upload again. We have in git a debian/0.3.1-1 tag which is now updated. If you want I can have care of removing it. kind regards Package flexparser re-uploaded, and I also granted you upload rights for flexcache that was accepted. Thanks for your contribution, Cheers, Thomas Goirand (zigo)
Re: QA Experiment: removing "stale uploaders"
Hi, This is a very reasonable thing to do considering the policy change. I also have two packages where I mistakenly ended up as the maintaner and DPT as uploader (see python-graphene-directives and python-graphene-federation) because of tooling defaults and me missing to see it in the end. I have been contemplating since I realized this about how urgently I should take care of this. What I mean is that, does this call for an immediate revision of the debian package, or is it sufficient to have a git commit to reverse it and then later upload it with the next possible upstream release. Thoughts? PS: And depending on how strictly we want to enforce this, there can perhaps also be a lintian warning/error? Best, Ananthu On 15 August 2024 8:45:24 pm UTC, "Louis-Philippe Véronneau" wrote: >5. Some of the packages flagged as "Debian Python Team" have the team as >Uploaders. Considering the recent policy change, we should probably try to >make things more uniform by having the DPT as maintainer everywhere.
Re: basemap
Am Thu, Aug 01, 2024 at 09:14:01AM +0200 schrieb Alexandre Detiste: > If the upstream tarball is really 3 projects duct-taped together we could > maybe import it in 3 different sources packages. The mk-orig-tgz would be a > tad complicated, but build would be easy again. That needs checking. Sorry for my late reply - I did not read this list for some time. I think the mk-orig-tgz does not need to be that complicated. I imagine we could add Files-Excluded: OTHER_PROJECT1_DIR OTHER_PROJECT2_DIR into each d/copyright and by doing so excluding stuff we do not want. I havn't checked the actual package but wanted to throw in that idea. Kind regards Andreas. -- https://fam-tille.de
Re: Policy Change Proposal: Running the upstream test suite
Am Wed, Aug 14, 2024 at 06:09:15PM -0400 schrieb Louis-Philippe Véronneau: > It's been about 2 weeks since the policy change has been proposed. I believe > I have taken in account the feedback and the discussion seems to have died > down. > > As the response from the team member was largely positive, I propose the > change be merged. Thank you for driving this forward Andreas. -- https://fam-tille.de
Re: dh_python for single python scripts?
Hey Stefano. (Thanks, also Andrey). On Fri, Aug 16, 2024 at 9:47 AM Stefano Rivera wrote: > > Is that even intended to work with dh_python? > > dh_python doesn't care what form your python package is in. It just > looks for the metadata in .dist-info / .egg-info. Then there must be something I do wrong. What I have is: - src/my-script-file.py (yes, hyphens here, which would of course be bad if it were a package - maybe this is the reason for my troubles?) - pyproject.toml [project] name = "my-script" requires-python = ">=3.11" dynamic = ["version"] dependencies = [ "numpy" ] [build-system] requires = ["setuptools>=61.0.0", "setuptools_scm[toml]>=6.2.0"] build-backend = "setuptools.build_meta" [tool.setuptools] script-files = ["src/my-script-file.py"] [tool.setuptools_scm] At first I tried: [project.scripts] my-script = "my-script:main" instead of the script-files = ["src/my-script-file.py"] But that didn't really work (which I guess is no surprise) as project.scripts expects a packge/module to load from, but my-script is none. With script-files = ["src/my-script-file.py"], the result from: python3 -m build --no-isolation *does* include my script at, and the Debian package also places it in /usr/bin - but I somehow get that my-script-file "into" Python. "into Python" is what I wrote before, namely when I run ptpython and use the completion of import my... it shows me my-script-file as if it were a module. So I think something is still wrong, but I cannot find out what. With the above pyproject.toml, the Debian package would contain: drwxr-xr-x root/root 0 2024-08-15 23:56 ./ drwxr-xr-x root/root 0 2024-08-15 23:56 ./usr/ drwxr-xr-x root/root 0 2024-08-15 23:56 ./usr/bin/ -rwxr-xr-x root/root109240 2024-08-15 23:56 ./usr/bin/my-script-file.py drwxr-xr-x root/root 0 2024-08-15 23:56 ./usr/lib/ drwxr-xr-x root/root 0 2024-08-15 23:56 ./usr/lib/python3/ drwxr-xr-x root/root 0 2024-08-15 23:56 ./usr/lib/python3/dist-packages/ drwxr-xr-x root/root 0 2024-08-15 23:56 ./usr/lib/python3/dist-packages/my_script_file-1.0.0.dist-info/ -rw-r--r-- root/root 7 2024-08-15 23:56 ./usr/lib/python3/dist-packages/my_script_file-1.0.0.dist-info/INSTALLER -rw-r--r-- root/root 1824 2024-08-15 23:56 ./usr/lib/python3/dist-packages/my_script_file-1.0.0.dist-info/METADATA -rw-r--r-- root/root91 2024-08-15 23:56 ./usr/lib/python3/dist-packages/my_script_file-1.0.0.dist-info/WHEEL -rw-r--r-- root/root 1 2024-08-15 23:56 ./usr/lib/python3/dist-packages/my_script_file-1.0.0.dist-info/top_level.txt drwxr-xr-x root/root 0 2024-08-15 23:56 ./usr/share/ drwxr-xr-x root/root 0 2024-08-15 23:56 ./usr/share/doc/ drwxr-xr-x root/root 0 2024-08-15 23:56 ./usr/share/doc/my-script-file/ -rw-r--r-- root/root 169 2024-08-15 23:56 ./usr/share/doc/my-script-file/changelog.Debian.gz -rw-r--r-- root/root 1373 2024-08-15 23:56 ./usr/share/doc/my-script-file/copyright So it retains the hypens, execpt for the dir in dist-packages, where it replaces them with _. It also generates a postinst: #!/bin/sh set -e # Automatically added by dh_python3 if command -v py3compile >/dev/null 2>&1; then py3compile -p my-script-file fi if command -v pypy3compile >/dev/null 2>&1; then pypy3compile -p my-script-file || true fi # End automatically added section Which I guess makes no sense (as there is no such package), or does it? And accordingly a prerm. btw: When I rename the src/my-script-file.py to src/my-script-file (no extension), then the contents of the .deb look the same, but the postinst/prerm are gone. Still I fail to understand, where that auto-completed my-script-file comes from in ptpython. Any ideas what I'm doing wrong? > So, if your package declares dependencies in in the packaging, and > installs correctly with python3-build, it'll work. I had some stupid mistake in my pyproject.toml, after noticing that, it correctly "auto-detected" the dependencies from that and translated them into Debian package names :-) Thanks, Philippe
Re: QA Experiment: removing "stale uploaders"
On 2024-08-16 9 h 09 a.m., weepingclown wrote: Hi, This is a very reasonable thing to do considering the policy change. I also have two packages where I mistakenly ended up as the maintaner and DPT as uploader (see python-graphene-directives and python-graphene-federation) because of tooling defaults and me missing to see it in the end. I have been contemplating since I realized this about how urgently I should take care of this. What I mean is that, does this call for an immediate revision of the debian package, or is it sufficient to have a git commit to reverse it and then later upload it with the next possible upstream release. Thoughts? Feel free to commit and not make a new release. I don't think anything is urgent. PS: And depending on how strictly we want to enforce this, there can perhaps also be a lintian warning/error? Lintian can't be used to generate this kind of information, as it only has access to the source and binary packages, not the git history. I feel relying on d/changelog for this doesn't provide enough information. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: dh_python for single python scripts?
Hey again On Fri, Aug 16, 2024 at 6:26 PM Philippe Cerfon wrote: > Still I fail to understand, where that auto-completed my-script-file > comes from in ptpython. > Any ideas what I'm doing wrong? Maybe it's not me doing something wrong. I have: ls -al /usr/bin/*.py lrwxrwxrwx 1 root root 45 Jun 25 00:44 /usr/bin/clang-tidy-diff-16.py -> ../lib/llvm-16/share/clang/clang-tidy-diff.py -rwxr-xr-x 1 root root 15k Jan 4 2024 /usr/bin/lsusb.py -rwxr-xr-x 1 root root 5,8k Aug 14 19:31 /usr/bin/mesa-overlay-control.py -rwxr-xr-x 1 root root 3,5k Aug 12 2021 /usr/bin/pfs_split_exposures.py lrwxrwxrwx 1 root root 33 Jun 25 00:44 /usr/bin/run-clang-tidy-16.py -> ../lib/llvm-16/bin/run-clang-tidy And all these names are also auto-completed in ptpython when trying to import. Maybe what's left, though, are these py3compile calls, which - I guess dh_python - makes, but which are probably not working in my case? Thanks, Philippe.
Re: Policy Change Proposal: Running the upstream test suite
Hi, Louis-Philippe Véronneau wrote on 15/08/2024 at 00:09:15+0200: > On 2024-07-29 4 h 53 a.m., Louis-Philippe Véronneau wrote: >> Hello, >> As discussed during the DebConf24 Python BoF, I'm submitting this >> change to the policy to require the use of the upstream test suite, >> both during the build process and as an autopkgtest. >> You can find the MR here: >> https://salsa.debian.org/python-team/tools/python-modules/-/ >> merge_requests/24 >> People present at the BoF seemed to think this was a good idea. If >> you don't please reply to this message and make yourself heard :) >> Cheers, >> > > Hi, > > It's been about 2 weeks since the policy change has been proposed. I > believe I have taken in account the feedback and the discussion seems > to have died down. > > As the response from the team member was largely positive, I propose > the change be merged. > > Cheers, I'm still against this, and I'm not sure yet whether or not it'll drive me to leave the team. The first sentence is ok, but the second is not ok with me. Regards, -- PEB signature.asc Description: PGP signature
Re: new dependencies for python-pint
Il 16/08/24 12:32, Thomas Goirand ha scritto: On 8/16/24 08:13, Antonio Valentino wrote: Dear Thomas, Il 15/08/24 09:33, Thomas Goirand ha scritto: On 8/15/24 08:10, Antonio Valentino wrote: Il 14/08/24 22:32, Thomas Goirand ha scritto: Hi, My answer below. On 8/12/24 08:04, Antonio Valentino wrote: Il 09/08/24 21:08, Antonio Valentino ha scritto: Dear Thomas, dear all, a new version (0.24.3) of python-pint is available upstream. It introduces two additional dependencies: flexcache and flexparser. I have files two ITP bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078258 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078260 and prepared the debian packages in salsa: https://salsa.debian.org/python-team/packages/flexparser https://salsa.debian.org/python-team/packages/flexcache I uploaded both. Thanks for your contrib! Thanks you for uploading. Please do not forget to grant me upload rights as per [1] so that I can to future uploads by myself. [1] https://wiki.debian.org/DebianMaintainer#Granting_Permissions Will do when it clears the NEW queue (otherwise it wont work). Please ping me when the package does. flexcache has been accepted. Once I get upload permissions granted I will proceed with the source only upload. Unfortunately flexparser has bee rejected due to incomplete d/copyright file. I'm sorry for that. I have now fixed it in git and I kindly ask you to review/upload again. We have in git a debian/0.3.1-1 tag which is now updated. If you want I can have care of removing it. kind regards Package flexparser re-uploaded, and I also granted you upload rights for flexcache that was accepted. Thanks for your contribution, Cheers, Thomas Goirand (zigo) Thanks again -- Antonio Valentino
Re: dh_python for single python scripts?
On Fri, Aug 16, 2024 at 11:02:18PM +0200, Philippe Cerfon wrote: > Hey again > > On Fri, Aug 16, 2024 at 6:26 PM Philippe Cerfon wrote: > > Still I fail to understand, where that auto-completed my-script-file > > comes from in ptpython. > > Any ideas what I'm doing wrong? > > Maybe it's not me doing something wrong. > I have: > ls -al /usr/bin/*.py This is against the Policy 10.4 by the way: "When scripts are installed into a directory in the system PATH, the script name should not include an extension such as .sh or .pl that denotes the scripting language currently used to implement it." -- WBR, wRAR signature.asc Description: PGP signature
