Multi-language support: which ones to do next?

[caarlos0]

Here's the place for you to share which languages and integrations you think should be added next!

Make sure to check if some suggestion was already given, and give it a thumbs up (and/or comment on the thread).

Cheers!

[jon4hz]

Support for python (incl. poetry) would be amazing!

[FollowTheProcess]

it would be awesome if you have more info on how you expect these things to work :)

Not OP but I do a fair bit of python as well as Go, in case you weren't aware, the python ecosystem is (slowly) standardising on the following:

• https://peps.python.org/pep-0517/
• https://peps.python.org/pep-0518/
• https://peps.python.org/pep-0621/

Precisely to allow basically any build system to know what to do to build python projects. The recommended way of doing this is to define a PEP-621 compliant pyproject.toml (tools like hatch, uv, pdm etc. use this format by default. poetry has only just caught up to supporting this format in v2) that declares a build dependency and build backend like so:

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

Then python -m build (https://github.com/pypa/build) will "just work™" and you'll get a wheel out, that can later be pushed to PyPI etc. Tools often implement their own build command e.g. uv build, poetry build etc. but these for the large part do the same thing as pypa/build.

I'm imagining GoReleaser's place in the python ecosystem as more of an orchestrator, tying together the build process with all the extra release goodies that people would otherwise have to implement themselves. Tools like https://github.com/astral-sh/uv handle a lot of the internal "pythony" details (which are v messy/complex and I would advise GoReleaser to stay away from IMO).

My recommendation would be GoReleaser support building:

• Pure python packages (no extension modules - python modules written in Rust/C etc. that must be compiled at build time)
• Defined using a PEP-621 pyproject.toml
• And a PEP-517/518 compliant build backend
• By effectively shelling out to python -m build

By doing the above you'll end up producing a standards compliant python wheel, using standard tooling that the rest of the ecosystem knows exactly what to do with. Future enhancements may follow but this is a good place to start IMO

I'm a long time GoReleaser user so I'd be happy to help here :)

[caarlos0]

nice! that's good input for sure, thank you for that!

yes, i was thinking about doing the "orchestration" thing, yes.

So, a "regular" python-thing software release would be like:

• python -m build to build the wheel file
• create archives (or just upload the wheel directly to the release?)
• create docker images (copy wheel ...; run pip install wheel)
• create Github release and what not
• optionally push wheel to PyPi

is that correct?

[ryancurrah]

Yep that seems correct to me.

[caarlos0]

another piece of that, how are linux packages generally created in these scenarios? like, where does the wheel go?

[FollowTheProcess]

• python -m build to build the wheel file ✅
  • and the sdist, effectively just a tarball of the source code, it's created by default by python -m build
• create archives (or just upload the wheel directly to the release?) ✅
  • I tend to just upload the wheel and sdist directly to the release when I do this yeah, python -m build will put both into the ./dist directory so I just upload everything under there normally
• create docker images (copy wheel ...; run pip install wheel) ❓
  • I think this should be optional personally? Python packages don't need images creating, but maybe if you're building an application and want to ship it as an image then yeah sure!
• create Github release and what not ✅
• optionally push wheel to PyPi ✅
  • Typical behaviour is to publish both the wheel and source distribution (sdist), both of which will be created by python -m build. The "standard" way to do this is with https://github.com/pypa/twine/. The other thing we might want here is trusted publishing with OIDC but not sure if that's out of scope or not (maybe a follow up). It's what https://github.com/pypa/gh-action-pypi-publish does

how are linux packages generally created in these scenarios? like, where does the wheel go?

This I don't know I'm afraid

[polothy]

At work, we use Go, Python and TypeScript.

[caarlos0]

on typescript, what would you expect goreleaser to do, build-wise?

[polothy]

Hrm, I'm probably not the best to answer that - but I feel like pip and npm sort of just handle everything already so goreleaser would just be a wrapper. I'm not even sure if publishing to GitHub releases and brew tap would be useful for these languages like it is for Go.

[caarlos0]

That's my impression too

[ryancurrah]

You could upload the resulting wheel to the release.

[ryancurrah]

Here is an example release with the wheel https://github.com/google-coral/pycoral/releases/tag/v2.0.0

pip install https://google-coral.github.io/py-repo/tflite-runtime/tflite_runtime-2.5.0.post1-cp39-cp39-linux_x86_64.whl

[caarlos0]

TypeScript with Bun: ✅

https://goreleaser.com/customization/bun-builds/

[caarlos0]

TypeScript with Deno: ✅

https://goreleaser.com/customization/builds/deno/