Versioneer [was Re: a review of your bumblebee-status package]

2022-06-07 Thread Timo Röhling

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?

2022-04-26 Thread Timo Röhling

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?

2022-04-24 Thread Timo Röhling

* 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?

2022-04-24 Thread Timo Röhling

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?

2022-04-18 Thread Timo Röhling

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

2021-10-18 Thread Timo Röhling

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

2021-06-09 Thread Timo Röhling

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