search

vi / websocat

Command-line client for WebSockets, like netcat (or curl) for ws:// with advanced socat-like functions
MIT License
7.01k stars 272 forks source link

Binaries naming scheme in release #148

Open leucos opened 2 years ago

leucos commented 2 years ago

The current naming scheme for released binaries is not predictable (architecture is not always present in the binary name).

Would it be possible to have a more consistent naming scheme for the released binaries so it is easier to automate a generic installation process for this tool (e.g. with binenv for instance) ?

Thanks !

vi commented 2 years ago

Releases are currently created semi-manually, using different script compared to before. Rather often the script requires some readjustment when I need to create a release again. They may be not reproducible (and maybe I cannot build anymore the old releases as my build environment evolves). They are intended to be used when package manager version is unavailable, yet end user does not want to mess with installing Rust toolchain, etc. All the files are (currently) cross-compiled from the same system I use for development. Some files may be built by Nightly, some by Stable, some by some Docekrized environment. Zig and also various downloaded gcc toolchains are used for linking. Bringing order to that chaos may be one of steps for releasing Websocat v3 (e.g. Dockerizing everything and ideally making builds reproducible). If Websocat is aimed at some serious usage, building instead of downloading is encouraged.

File name is indeed inconsistent and may name architecture by Rust's architecture name, Debian arch name or some trivial name like "linux32". My release script typically contains mapping between Rust archs triplets and shorter trivial names.

What naming scheme do you suggest? Are there any common recommended good practices used in other projects? How long should the names be - isn't including the full triplet (quadruplet?) and also features combination too bulky?

leucos commented 2 years ago

Although I do not know Rust and probably miss some of its specifics, what I usually see is a combination of architecture/os in the final binary names.

Names used vary between projects (e.g. darwin, MacOS, macos, ...; x86_64, amd64, ...), but once you know which ones a project uses, you can predict binary names and their download URL.

Not sure there are any specific good practices in this area. And I would not risk myself into making recommandations since I know nothing about Rust, and it is also a project decision. I would say that this is not even a problem.

But in my case (as maintainer of a helper tool already mentioned above that let one's install binaries), it would be much easier to be able to generate download links according to the architecture and OS.

Here are a few examples selected at random:

vi commented 2 years ago

https://github.com/starship/starship/releases https://github.com/chmln/sd/releases

Seems like they are using full target triplets, even with the redundant "-unknown-". If it is becoming the expected way of doing things, maybe I should start naming release files also without any conversions.

I expect I should not go and rename files in existing release, just reform the scheme for further releases.

bdellegrazie commented 2 years ago

Hi, I'm trying to adjust the asdf plugin for websocat to correctly determine the download URL of websocat for the newer versions (https://github.com/bdellegrazie/asdf-websocat/pull/2), yes this is currently broken.

However without a stable naming convention, I cannot do this. For what I consider the most typical case (x86_64 linux) I cannot easily determine which one to download with the new convention used by v1.10

Ideally I'd need to know what each "section" of the release URL corresponds to - I can see architecture but what are the other 3 parts of the set and what do they mean? and can we consistently use them for all binaries?

Thanks in advance,

Brett

vi commented 2 years ago

Current scheme for naming pre-built executables for new releases for Websocat (and other projects) is like this:

project_name [ "_" compile-time_settings] "." rust_target_name [ "." filename_extension]

rust_target_name is like in this table. project_name is the name of primary Cargo package, maybe with dashes and underscores removed, maybe with -bin removed if there is one.

Why Rust targets have all those "unknown"s is another question (which is out of scope), but I saw other Rust projects naming their release artifacts in a similar way (i.e. using Rust target names as is, without removing any excessive parts).

bdellegrazie commented 2 years ago

@vi thank you!