v2.1 - December 15th 2023
Two years ago, I started to modify AV-98 in order to browser Gemini
offline.
https://ploum.net/2021-12-06-offline-av98.htmlhttps://ploum.net/2021-12-17-offline-gemini.html
It is interesting to reflect on those last two years and look at what
this little experiment has become. A tool I use daily. In fact, on of my
main tools with Neovim and Neomutt. Also a community. People
contributing. Sending patches, bug reports or even thank you notes. A
few people hanging out on the offpunk:matrix.org room. I’m really
grateful for that and for all the people who make the Gemini-sphere
alive.
This 2.1 release is also a more relaxed release. The 2.0 release was
well received, widely packaged and has very few bugs (comparing to 1.0).
So nothing ground breaking but, besides a few bug fixed (including the
infamous gemini redirection bug), some little nice-to-have features.
Like highlighting "new links" in Gemini and RSS pages. I was unsure if
it would work, turns out that it is the best thing ever invented to read
Gemini Antenna or long RSS feeds.
Also added: "copy title" and "copy link", allowing you to quickly
reference a page in a personnal note or an email.
And, one day, I realized that I often wanted to know where a given link
was pointing to (a bit like hovering your mouse on a link in a
traditional browser). So I added a "view XX" where XX is the number of
the link.
What is really interesting with this feature is how I wrote it: I
realized I had a need, opened the offpunk.py, wrote a few lines of code
to test it and… that was it. No correction to do. It was good at the
very first try. Which is a testament to the fact that the 2.0
refactorisation was actually a good thing.
So, here is it, the 2.1 release. Enjoy!
Changelog since 2.0:
- freshly updated gemtext/rss links are highlighted ("new_link" theme option)
- offpunk : new "copy title" and "copy link" function
- offpunk : new "view XX" feature where XX is a number to view information about a link
- ansicat: added "--mode" option
- redirections are now reflected in links and the cache (bug #28)
- ansicat: avoid a crash when urllib.parse.urljoin fails
- offpunk: Fix a crash when gus is called without parameters (Von Hohenheiden)
- ansicat: fixed a crash when parsing wrong hidden_url in gemini (bug #32)
- offpunk: offpunk --version doesn’t create the cache anymore (bug #27)
- ansicat: fix a crash with HTML without title (bug #33)
- netcache: gemini socket code can crash when IPv6 is disabled (mailing-list)
--
Ploum - Lionel Dricot
Blog: https://www.ploum.net
Livres: https://ploum.net/livres.html
Ploum wrote:
> v2.1 - December 15th 2023
Congratulations with the release!
Should the “__version__” variable reflect the release version?
The TOML file references the version and a v2.0 egg will be built. And when installed the *.dist-info directory will have a METADATA file that says
Metadata-Version: 2.1
Version: 2.0
Cheers,
--
Kʟᴀᴜꜱ Aʟᴇxᴀɴᴅᴇʀ Sᴇɪꜱᴛʀᴜᴘ 🇩🇰
https://magnetic-ink.dk/kas
On 23/12/12 04:30, Klaus Alexander Seistrup wrote:
>Ploum wrote:>>> v2.1 - December 15th 2023>>Congratulations with the release!>>Should the “__version__” variable reflect the release version?
DAMN! Once again. I always forget this one. I should really do a
"do_release" script which check this (and change it).
What’s the best way to fix this ? A 2.1.1 release ?
>>The TOML file references the version and a v2.0 egg will be built. And when installed the *.dist-info directory will have a METADATA file that says>> Metadata-Version: 2.1> Version: 2.0>>Cheers,>>-->Kʟᴀᴜꜱ Aʟᴇxᴀɴᴅᴇʀ Sᴇɪꜱᴛʀᴜᴘ 🇩🇰>https://magnetic-ink.dk/kas>
--
Ploum - Lionel Dricot
Blog: https://www.ploum.net
Livres: https://ploum.net/livres.html
> DAMN! Once again. I always forget this one. I should really do a > "do_release" script which check this (and change it).
You could also use one of the hatchling plugins listed here:
https://hatch.pypa.io/latest/plugins/version-source/reference
to automatically use the latest Git tag as the version.
Ploum wrote:
> I always forget this one.
I would, too. :)
> What’s the best way to fix this ? A 2.1.1 release ?
Or you could just be quick and pretend nothing has happened. ;)
Honestly, I don't know how significant these numbers are.
The ArchLinux package will always fetch the latest git commit and calculate a version that uses the tag (that has correctly been set to v2.1) + the commit hash, so any change you make will be accepted.
I'm unsure about other distros.
Cheersm
--
Kʟᴀᴜꜱ Aʟᴇxᴀɴᴅᴇʀ Sᴇɪꜱᴛʀᴜᴘ 🇩🇰
https://magnetic-ink.dk/kas
On 23/12/12 04:42, Klaus Alexander Seistrup wrote:
>Ploum wrote:>>> I always forget this one.>>I would, too. :)>>> What’s the best way to fix this ? A 2.1.1 release ?>>Or you could just be quick and pretend nothing has happened. ;)
I amended the commit and forced the push. It seems everything is right,
nobody saw it.
Very very bad practice… But, hey, I’m not one of those good guys ;-)
On 23/12/12 04:41, Jean Abou Samra wrote:
>> DAMN! Once again. I always forget this one. I should really do a>> "do_release" script which check this (and change it).>>>You could also use one of the hatchling plugins listed here:>https://hatch.pypa.io/latest/plugins/version-source/reference>to automatically use the latest Git tag as the version.
Will investigate that, it really makes sense! Thanks.
--
Ploum - Lionel Dricot
Blog: https://www.ploum.net
Livres: https://ploum.net/livres.html
Ploum wrote:
> I amended the commit and forced the push.
Please note that “git describe” now says we have v2.0:
$ git describe --long --abbrev=7
v2.0-14-g1bbd317
So the ArchLinux package will seemingly downgrade from v2.1.* to v2.0.*.
--
Kʟᴀᴜꜱ Aʟᴇxᴀɴᴅᴇʀ Sᴇɪꜱᴛʀᴜᴘ 🇩🇰
https://magnetic-ink.dk/kas
On Tuesday, December 12th, 2023 at 17:12, Klaus Alexander Seistrup <klaus@seistrup.dk> wrote:
> > > Ploum wrote:> > > I amended the commit and forced the push.> > > Please note that “git describe” now says we have v2.0:> > $ git describe --long --abbrev=7> v2.0-14-g1bbd317
How is it possible? How does it take its value?
Ploum wrote:
> How is it possible? How does it take its value?
It gets the value from the git blockchain. I guess the “amend” thing b0rked something.
Do you get something else when you run “git describe --long” in the repo?
The AUR package is using “git describe” to construct a unique package version for each commit:
🔗 https://wiki.archlinux.org/title/VCS_package_guidelines#Git
Cheers,
--
Kʟᴀᴜꜱ Aʟᴇxᴀɴᴅᴇʀ Sᴇɪꜱᴛʀᴜᴘ 🇩🇰
https://magnetic-ink.dk/kas
Le mardi 12 décembre 2023 à 16:22 +0000, Ploum a écrit :
> On Tuesday, December 12th, 2023 at 17:12, Klaus Alexander Seistrup <klaus@seistrup.dk> wrote:> > > $ git describe --long --abbrev=7> > v2.0-14-g1bbd317> > How is it possible? How does it take its value?
Git commits are immutable. When you create a tag, it carries
the ID of the commit that is being tagged. When you run
`git commit --amend`, it doesn't modify the existing commit
(since commits are immutable), it creates a new commit
with the same ancestor as the old commit and updates
the branch to point to that new commit. But the tag
still points to the old commit.
On 23/12/12 05:35, Jean Abou Samra wrote:
>Le mardi 12 décembre 2023 à 16:22 +0000, Ploum a écrit :>> On Tuesday, December 12th, 2023 at 17:12, Klaus Alexander Seistrup <klaus@seistrup.dk> wrote:>>>> > $ git describe --long --abbrev=7>> > v2.0-14-g1bbd317>>>> How is it possible? How does it take its value?>>>Git commits are immutable. When you create a tag, it carries>the ID of the commit that is being tagged. When you run>`git commit --amend`, it doesn't modify the existing commit>(since commits are immutable), it creates a new commit>with the same ancestor as the old commit and updates>the branch to point to that new commit. But the tag>still points to the old commit.
I modified the tag to point to the new commit. All seems to be in order
in git log or even on sourcehut where v2.1 is pointing to master (commit
1bbd317)
Yet, git describe fails to catch it.
--
Ploum - Lionel Dricot
Blog: https://www.ploum.net
Livres: https://ploum.net/livres.html
On 23/12/12 05:30, Klaus Alexander Seistrup wrote:
>Ploum wrote:>>> How is it possible? How does it take its value?>>It gets the value from the git blockchain. I guess the “amend” thing b0rked something.>>Do you get something else when you run “git describe --long” in the >repo?
Gotcha! The tag had become a standard non-annotated tag. Just pushed a
new annotated tag, should be fine now
> I modified the tag to point to the new commit. All seems to be in order> in git log or even on sourcehut where v2.1 is pointing to master (commit > 1bbd317)> > Yet, git describe fails to catch it.
It works for me. In a fresh clone:
$ git describe --long --abbrev=7
v2.1-0-g1bbd317
Ploum wrote:
> Just pushed a new annotated tag, should be fine now
Thanks. I bumped the package “epoch” on AUR because the old “g765f8f6-1” > the new “g1bbd317”, so now we're going from “2:2.1.r0.g765f8f6-1” to “3:2.1.r0.g1bbd317-1”.
That should solve it.
Thanks.
--
Kʟᴀᴜꜱ Aʟᴇxᴀɴᴅᴇʀ Sᴇɪꜱᴛʀᴜᴘ 🇩🇰
https://magnetic-ink.dk/kas