Multiple conflicting command-line tools called ulid exist

[musicinmybrain]

Both this project and https://github.com/oklog/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 https://github.com/mdomke/python-ulid/issues/13 may or may not also be relevant, depending on the response.

[musicinmybrain]

https://github.com/oklog/ulid/issues/111

[musicinmybrain]

Based on discussion in https://github.com/oklog/ulid/issues/111, the conflict in Fedora is resolved beginning with Fedora 40 by renaming the other package’s binary from /usr/bin/ulid to /usr/bin/ulid-go in https://src.fedoraproject.org/rpms/golang-github-oklog-ulid/pull-request/1. However, I’m leaving this issue open because ulid is still a pretty generic name considering how many implementations of ULIDs exist, and there may still be a case for renaming – especially considering https://github.com/mdomke/python-ulid/issues/13. Feel free to close this issue if no change is planned.