RFE: is it possible to start making github releases?🤔

[kloczek]

Is it possible next time on release new version make the github release to have entry on https://github.com/fsspec/filesystem_spec/releases? 🤔

I'm only asking because on the creation of a new GH release a notification is spread to all those whom have set in the web UI Watch->Releases.

My automation process uses those notifications by trying to make preliminary automated upgrades of building packages, which allows saving some time on maintaining packaging procedures.

More about gh releases is possible to find on https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository https://github.com/marketplace/actions/github-release https://pgjones.dev/blog/trusted-plublishing-2023/ https://github.com/ESSS/pytest-regressions/commit/bcd06142 https://github.com/jbms/sphinx-immaterial/issues/281#issuecomment-1700933026

[martindurant]

I am not particularly keen to take on another task in the release process, even though it can be automated (and can fail!). For your workflow, is it not possible to get a notification from pypi or watch the feedstock repository?

[kloczek]

I'm working on Linux/Solaris distribution in which python modules are only fraction of the packages. At he moment ,ore than 4/5 of all source trees are maintained on github. Are you really not interested to spread new release notifications to those who are interested you module? 🤔

[martindurant]

Are you really not interested to spread new release notifications to those who are interested you module?

I know this is a joke, but actually end users only relatively rarely are aware of the version of fsspec that they are using, because it typically gets installed as a dependency of something else. The low numbers of watchers/forks/stars on this repo is completely at odds with our download statistics.

[kloczek]

Your repo has 21 watches.

[martindurant]

Yes, and 3-4M downloads per day https://pypistats.org/packages/fsspec , easily number 1 of all packages at Anaconda (at least on pypi).

[ianthomas23]

xref mesonbuild/meson-python#484

[eli-schwartz]

Yup -- for a bit of context, this ticket is NOT representative of most people working in the

Linux/Solaris distribution

space, who tend to rely heavily on very flexible automation that has been built up over years or decades to cope with a profound abundance of software types, distribution models, and preferred upstream-maintainer-approach for announcing releases, and make it easy to plug in a template to any software package and pull in the release announcements for monitoring.

This copes with:

• git repositories, by running git ls-remote and scraping tags
• regex applied to artisanal HTML pages maintained by people who never "fell for that VCS claim"
• RSS feeds provided by github or PyPI or many, many other sources
• github's REST api
• gitlab's REST api

with plugins for auto-mangling versions e.g. stripping out "release-" from a tag named "release-1.2.0" for correct version sorting

and that's just the tip of the iceberg.

See for example https://release-monitoring.org/ which is developed by Fedora, with a long list of data ingestion types: https://release-monitoring.org/static/docs/user-guide.html#backends Debian's standard is that every package should have https://wiki.debian.org/debian/watch

Most people in the distro space don't want to rely on github email notifications, since those are way too easy to not notice, or only get seen by one person, or don't update status pages, or....

[martindurant]

Thanks for the feedback, everyone. I am not principally opposed to github releases, if it can be done automatically and costs me nothing. If someone implements that as a PR, great. Closing this for now, however, as there's not much more to discuss.

[kloczek]

if it can be done automatically and costs me nothing. If someone implements that as a PR, great.

Looks like what is described on https://github.com/marketplace/actions/github-release can be added to https://github.com/fsspec/filesystem_spec/blob/master/.github/workflows/pypipublish.yaml and indeed it will be one time change. Additionally it will be necessary to generate github API token to be able use GH API call

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Create a Release
      uses: elgohr/Github-Release-Action@v4
      env:
        GITHUB_TOKEN: ${{ secrets.RELEASE_TOKEN }}

AFAIK `with: is not necessary because in absence of the message it will be autogenerated email Subject with git tag name ot top of which gh release will be added.

PS. TBH personally I've never been using gh actions and releases and and if above it is not enough for you I think that I should try to create some test repo to test that before try submit PR.