Multiple conflicting command-line tools called ulid exist

[musicinmybrain]

Both this project and https://github.com/mdomke/python-ulid/ build executables called ulid. The purpose of this issue is to open a discussion about possibly renaming one or both of them so that they can co-exist without workarounds.

This is motivated by the Fedora Linux case; we already have a golang-github-oklog-ulid package that installs /usr/bin/ulid, and since https://github.com/pydantic/pydantic-extra-types added a dependency on https://github.com/mdomke/python-ulid/, we are now working on a python-python-ulid package as well. A quick survey suggests that we may be the first Linux distribution to package both projects. We have some guidelines about how to deal with binary name conflicts, and approaching the relevant upstreams about a possible renaming is the first step.

Ideally, one or both projects would rename the ulid binary to something more unique, so that distributions don’t have to deal with conflicting packages or choose their own way to rename binaries. The issue mdomke/python-ulid#13 may or may not also be relevant, depending on the response.

[musicinmybrain]

mdomke/python-ulid#14

[peterbourgon]

The name of the binary isn't defined by this repo, it's ultimately determined by the go build command which produces it. That appears to be defined in the Fedora package spec. Easy fix:

 %build
 --
   | for cmd in cmd/* ; do
-  | %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
+  | %gobuild -o %{gobuilddir}/bin/$(basename $cmd)-go %{goipath}/$cmd
   | done

Or, better yet, skip the loop:

 %build
 --
-  | for cmd in cmd/* ; do
-  | %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd
-  | done
+  | %gobuild -o %{gobuilddir}/bin/ulid-go %{goipath}/cmd/ulid

[peterbourgon]

Super cool the Python repo doesn't link back to this one, especially considering they copy-pasted our README 😎

[musicinmybrain]

The name of the binary isn't defined by this repo, it's ultimately determined by the go build command which produces it. […]

Thanks; this seems like good advice, and with your “blessing” for shipping the binary as ulid-go, I’ve proposed it to the maintainer of the package in https://src.fedoraproject.org/rpms/golang-github-oklog-ulid/pull-request/1. (I used a slightly different approach because I ran afoul of magic assumptions in the go rpm macros, but the effect is the same.)

[musicinmybrain]

Super cool the Python repo doesn't link back to this one, especially considering they copy-pasted our README 😎

mdomke/python-ulid#15

[peterbourgon]

Super cool the Python repo doesn't link back to this one, especially considering they copy-pasted our README 😎

mdomke/python-ulid#15

🙇

[musicinmybrain]

Beginning in Fedora 40, the binary built from this project is renamed from /usr/bin/ulid to /usr/bin/ulid-go. Thanks again for your input!

[mdomke]

@peterbourgon I'm sorry for not having linked back to this project. I have only mentioned the other Python implementations from the project's README, as well as the original spec https://github.com/ulid/spec. It is also the original spec from where I copied the logo and the claims, but the rest of the README is pretty specific to the Python implementation. What specifically do you mean with

they copy-pasted our README