tag releases

[anarcat]

hi,

I'm looking at how this software could be packaged for Debian and, to ease packaging and tracking, it would be quite useful to have real releases tagged for this software. Even a little 0.1 incremented once in a while would do wonders for easier packaging in Debian. Failing that, we'll have to package it using a silly version number like 0.0~gitYYYYMMDD-ffffff which is a sore for the eyes. :)

Thanks for your work!

[spl0k]

Yeah, I don't use any version numbering strategy. There's still a "0.3" defined that get incremented rather arbitrarily.

supysonic/supysonic/__init__.py

Line 12 in 270fa98

VERSION = '0.3'

Would you have any recommendation on the subject?

[anarcat]

there are many ways to pet that particular cat of course. :) In my projects, I follow Semantic Versionning as much as humanly possible. In your case, I think you could get away with issuing a 0.4.0 release next, and tag it (preferably signed) in git as well. When you push that tag on GitHub, you're basically done.

But then you get the problem of having to sync that silly version number in the __init__.py file. For that I have found setuptools_scm to be actually quite useful: when you build from git, it generates a static version number based on the git history (including tags). When you build/install from pip or similar, that version gets installed as a package resource that you can fetch dynamically, at runtime. That way you "Don't Repeat Yourself" (DRY) and keep one source of truth (git tags) for your version numbers.

But that's one step further: it's not absolutely necessary. It does help with the "gah, I forgot to edit __init__.py again" problem however. :)

Do keep in mind that anything touching pkg_resources can impose a significant performance impact on startup, adding between 200 and 500ms to startup times, because of pypa/setuptools#510. There are various workarounds for this, but I don't think they're especially relevant for a daemon like supysonic that we can afford to spend a little time starting up for. In any case, I would be happy to detail those workarounds if that's a real problem.

But TL;DR: (1) just git tag (2) using semver and optionnally (3) setuptools_scm. :)

I hope that helps!

[spl0k]

Ok thank you. I was planning to bump the version after some work on the watcher/scanner anyway (basically trying to get something that work for #124/#127).

Do keep in mind that anything touching pkg_resources can impose a significant performance impact on startup

🤔

supysonic/supysonic/db.py

Line 15 in 270fa98

import pkg_resources

It's used for database migrations.

[anarcat]

yeah, so you're already eating that cost it looks like. it's not critical, and hopefully we can just pretend like this will eventually fix itself in python instead of bending over backwards around it. at least i don't think startup time is critical for supybot's use case, although it could (for example) speed up the test suite if it loads db.py multiple times in the run.

[spl0k]

Here comes the first tagged and signed version!

[baldurmen]

Hurray! I'll have a look at trying to package supysonic for debian ;D

[spl0k]

I don't fully understand the lingo here, did pony reach the package repository?
Don't hesitate to nudge me if something should/could be done on Supysonic to ease the process.

[anarcat]

I don't fully understand the lingo here, did pony reach the package repository?

Not as far as I know.

Don't hesitate to nudge me if something should/could be done on Supysonic to ease the process.

Get rid of PonyORM? ;) Just kidding, that would probably be too much of an undertaking... @baldurmen will just have to package Pony first...

Thank you for the release!

[anarcat]

oh and i guess this can closed now then :)