Versioneer [was Re: a review of your bumblebee-status package]
Hi everyone, * Ben Westover [2022-06-06 22:42]: As far as I understand it, this file is used by the author of the program, not end users. I don't understand it well, though, because I haven't put much time into researching what versioneer even does. Versioneer is meant to simplify version tracking for the developer; it supports a number of authoritative sources such as "git describe" to determine the current version number. There are two modes of operation: - in developer mode, versioneer detects the version number dynamically. This is what you'll see if you use the (Git) repository sources. - in install mode, the release version number is statically embedded. This is what you'll see if you download from PyPI. Internally, these modes are realized by two different _version.py files; the developer version is usually added to version control, and the setuptools "build" and "sdist" steps are intercepted to insert the static _version.py as needed. In my experience, it Just Works with pybuild, so I wouldn't bother with any special treatment; the versioneer.py source is public domain, so you're not going to run into any licensing issues. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Messed up a salsa commit - how best to fix?
Hi Julian, * Julian Gilbey [2022-04-26 11:03]: It turns out that I'd also messed up more than I'd realised: even when I pulled in the updated master branch, I didn't pull the upstream branch, so managed to introduce even more conflicts. Oh well. It's an easy mistake to write "git pull" if you meant to do "gbp pull". I lost count how often I wrote "git pq" by accident... To fix the problem, I did: $ git checkout upstream $ git reset --hard upstream/5.3.0 Judging from the current commit graph, you probably threw in a "git merge -s ours origin/upstream" here as well? $ git checkout master $ gbp pristine-tar commit and that fixed everything. I finished with git push --all and git push --tags. Nice! I hope I don't make this mistake again! Don't worry about it too much. Git is quite resilient, and as long as you do not panic and start force-pushing random stuff, everything can be repaired. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Messed up a salsa commit - how best to fix?
* Timo Röhling [2022-04-24 22:42]: Make sure that your local upstream branch and the upstream/5.3.0 tag both point at commit 08935221b549bf32157d739cd54eb1645a2ab123: Aaaand I copied the wrong commit hash to the email. :/ e228e8902aeb91011a53bb1a91f7f3390a771e0e is the one you should be looking for: https://salsa.debian.org/python-team/packages/python-qtconsole/-/commit/e228e8902aeb91011a53bb1a91f7f3390a771e0e Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Messed up a salsa commit - how best to fix?
Hi Julian, * Julian Gilbey [2022-04-24 21:01]: Somehow I managed to really mess up a commit to python-qtconsole: the upstream and pristine-tar branches do not have the upstream/5.3.0 sources (the current ones). However, there's already an upstream/5.3.0 tag in the repository, pointing to a commit to the master branch. I think the simplest thing to do is to "rewrite history": delete the head commits to the master branch and the 5.3.0 tags, and then recommit correctly and force-push to salsa. Would people be OK with me doing this, or do you have an alternative suggestion? I looked at the Salsa repository, and it is not so bad. It seems like you forgot to pull the latest changes in upstream and pristine-tar from the 5.2.2 import first, so your import of 5.3.0 forked the those branches unintentionally. As the first order of business, you should run $ git fetch origin to update all your remote branches to the actual locations. Then, we can fix the branches one by one. For the pristine-tar branch, the easiest way is to rebase your commit to the actual remote branch that includes the 5.2.2 import by Frédéric: $ git checkout pristine-tar $ git rebase origin/pristine-tar $ git push origin pristine-tar The upstream branch cannot be rebased, because it is interwined with the master branch. Fortunately, that is not necessary, because the 5.2.2 import has been merged into master and therefore is connected in the graph. Make sure that your local upstream branch and the upstream/5.3.0 tag both point at commit 08935221b549bf32157d739cd54eb1645a2ab123: $ git -P log -n1 upstream $ git -P log -n1 upstream/5.3.0 If they do, you can $ git push --force origin upstream upstream/5.3.0 This will remove the 5.2.2 import from the upstream branch history, but it will not be lost because it is still connected to the master branch, which is arguably the more important connection, as it allows you to reproduce the 5.2.2 upload if required. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
rstcheck: how should I package the new public module?
Hi, rstcheck used to be a pure CLI application, so I packaged it as "rstcheck" with a private module in /usr/share/rstcheck. The latest version has added a public module interface, so "import rstcheck" has become a thing and the module needs to be installed publicly for that. My question is: should I move/rename the whole package to python3-rstcheck (and keep rstcheck temporarily as transitional dummy package), or should I keep /usr/bin/rstcheck in the old package indefinitely and only move the module to python3-rstcheck? The latter solution feels cleaner to me, because it neatly separates the library and the appliation, but at the cost of an almost empty binary package, which is frowned upon by the FTP team. Any suggestions how I should proceed? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: packaging help request: paths for build_py and build_scripts phases
Hi Jonathan,
* Jonathan Dowland [2021-10-18 11:04]:
Here, the scripts are copied to a path *not* rooted in <>.
So far as I can tell, both phases are normal parts of the
setuptools/distutils build lifecycle, and I haven't spotted anything
obviously non-standard about the way that is specified.
[...]
A BTS bug requesting the new version with some back-and-forth trying to
figure this out is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988597
The main issue is the implicit upstream assumption that the tests
are run from the source root dir; I've had a similar problem with
tweepy and my solution was to make sure that the tests find
everything they need in the build folder, i.e. add the following
snippet to d/rules:
export PYBUILD_BEFORE_TEST=cp {dir}/trash-* {dir}/script/bump.py {build_dir}
export PYBUILD_AFTER_TEST=rm {build_dir}/trash-* {build_dir}/bump.py
The second line is needed so the extraneous stuff is not installed
with the built package. It's not very pretty, and hopefully someone
else has a better solution, but it gets the job done.
You'll also have to patch tests/run_command.py to run python3 and
add python3-psutils to your Build-Depends.
diff --git a/tests/run_command.py b/tests/run_command.py
index 2e31e11..746cdad 100644
--- a/tests/run_command.py
+++ b/tests/run_command.py
@@ -17,7 +17,7 @@ def run_command(cwd, command, args=None, input='', env=None):
if args == None:
args = []
command_full_path = os.path.join(base_dir, command)
-process = subprocess.Popen(["python", command_full_path] + args,
+process = subprocess.Popen(["python3", command_full_path] + args,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
Cheers
Timo
PS. I worked around the missing fork
PPS. I thought about patching run_command.py to use the scripts from
the source directory, but that will use the trashcli module from the
source tree, not from the build tree, and contaminate the source tree
with __pycache__ folders.
--
⢀⣴⠾⠻⢶⣦⠀ ╭────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Team membership request
Hello! I'd like to join the team! Right now, I would like to help maintain the outdated Tweepy package which I'm currently using, but more generally, I am an avid Python user, so it would be my pleasure to help keep the Python package ecosystem in good shape. I'm also member of the Science Team, where I help maintain a number of (ROS related) Python packages. My Salsa login is roehling. I have read https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst and accept it. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
