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!

[ryancurrah]

Plus one to Python. We love Go Releaser and would like to use it for packing and distributing Python artifacts. Mostly Docker images and PyPi.

[caarlos0]

hey!

in the case of python, the build would do nothing, right?

isn't it basically archiving the source code and publishing to pypi? (+ docker and other features goreleaser allows to use)

[ryancurrah]

A Python build typically produces a wheel which is a binary distribution format that’s faster to install and doesn’t require users to compile from source. Python source code is typically compiled into an intermediate bytecode representation, which the Python interpreter then executes in a virtual machine-like environment.

setuptools is the long-standing standard tool for building these packages, while modern alternatives like poetry, flit, and hatch handle dependency management and packaging. For example, using poetry, running poetry build generates a wheel ready for PyPI and other distribution steps.

With GoReleaser’s Docker packaging, once you have a wheel ready, you could COPY it into the container image and run pip install ./your-package-name.whl to bundle your Python package and its dependencies into a final Docker image.

A wheel package itself contains a project’s dependency information, but not the actual dependency packages themselves. When you run pip install ./your-package-name.whl, pip uses the wheel’s metadata to locate and install any needed dependencies from PyPI (or another configured index).

[jon4hz]

It would be nice if you could also build system packages by using the nfpm functions if you want to distribute your app / library natively on linux.

[caarlos0]

so, been playing with python's wheel format.

I think that, since its not the same as binary, we might need to add a new artifact type for it (which is fine).

so, my todo list roughly is:

• new artifact type
• builder (supporting pip, uv, poetry, not sure which to default to)
• other pipes such as releases, docker, nfpm, archives, etc will need to add support for wheels, too

main reason is that, nfpm, for example, would have to put the wheel somewhere else I presume? (where?)

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

[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/