Consider putting forge macros in maintainance mode and deprecating them

gotmax23 commented

2026-05-06 21:09:39 +00:00

Owner

I am considering putting the forge macros in maintenance mode and deprecating them for a couple reasons. I believe the Go macros and fonts macros are the main users of the forge macros lua library, so my first goal before doing that would be to explore a different solution for those ecosystems. My proposed solution for the Go ecosystem is in https://gitlab.com/fedora/sigs/go/go2rpm/-/work_items/60 and that ticket has some more context as to why I view the forge macros as deficient. I'd like to explore a better path forward that still provides opportunities for automation while avoiding the need to memorize forge url formats or the need to maintain this project — a large pile of lua code that runs during specfile parsing and is difficult to maintain in a backwards compatible fashion.

gotmax23 commented

2026-05-06 21:20:44 +00:00

Author

Owner

To summarize the current issues I see with the forge macros:

The macros have some confusing magical behaviors — setting a bunch of macros dynamically with forgemeta, using source archive mtimes to determine git snapshot dates, adding data which is sometimes wrong to Release automatically (see #10), etc.
The macros are not compatible with the current Versioning Guidelines by default.
There's many changes (such as correcting the aforementioned magical behaviors) that are difficult to make to the macros without breaking backwards compatibility.
Nobody else has expressed interest in helping maintain the macros (see #6) other than me.
The macros are complicated to maintain and a frequent source of confusion and lack documentation. I did write limited unit tests which makes maintenance a bit easier, but the lack of comprehensive tests is a barrier.

I am not planning to propose a "Retire forge macros" Change or anything like that, but I would like move away from the forge macros, at least in the Go ecosystem.

To summarize the current issues I see with the forge macros: - The macros have some confusing magical behaviors — setting a bunch of macros dynamically with forgemeta, using source archive mtimes to determine git snapshot dates, adding data which is sometimes wrong to Release automatically (see #10), etc. - The macros are not compatible with the current Versioning Guidelines by default. - There's many changes (such as correcting the aforementioned magical behaviors) that are difficult to make to the macros without breaking backwards compatibility. - Nobody else has expressed interest in helping maintain the macros (see #6) other than me. - The macros are complicated to maintain and a frequent source of confusion and lack documentation. I did write limited unit tests which makes maintenance a bit easier, but the lack of comprehensive tests is a barrier. I am not planning to propose a "Retire forge macros" Change or anything like that, but I would like move away from the forge macros, at least in the Go ecosystem.

churchyard commented

2026-05-06 22:50:04 +00:00

Owner

I think that %forgesource could be replaced by a macro that takes URL or VCS tag and derives the source tarball URL from it (passing commit or tag as argument) and %forge(suto)setup could be replaced by %(auto)setup -C. The rest is magic that should IMHO not be needed. Perhaps a macro to conveniently construct a snapshot bit of the version tag.

gotmax23 commented

2026-05-14 17:09:04 +00:00

Author

Owner

For the go tooling, I am leaning towards handling this all in Python in go2rpm and just hardcoding the proper Source URLs (other than the %{version} part). But I am happy to participate a forge macros v2 effort if you or anyone else wants to work on that.

%forge(suto)setup could be replaced by %(auto)setup -C.

Indeed, being able to rely on %autosetup -C would definitely simplify this. There's a fair amount of forge macros code to figure out archive top directory names, and each forge has different edge cases when tags have slashes or other special characters.

For the go tooling, I am leaning towards handling this all in Python in go2rpm and just hardcoding the proper Source URLs (other than the `%{version}` part). But I am happy to participate a forge macros v2 effort if you or anyone else wants to work on that. > %forge(suto)setup could be replaced by %(auto)setup -C. Indeed, being able to rely on `%autosetup -C` would definitely simplify this. There's a fair amount of forge macros code to figure out archive top directory names, and each forge has different edge cases when tags have slashes or other special characters.

Rows
Columns

Consider putting forge macros in maintainance mode and deprecating them #14