Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple conflicting command-line tools called ulid exist #14

Open
musicinmybrain opened this issue Jan 31, 2024 · 2 comments
Open

Multiple conflicting command-line tools called ulid exist #14

musicinmybrain opened this issue Jan 31, 2024 · 2 comments

Comments

@musicinmybrain
Copy link
Contributor

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 #13 may or may not also be relevant, depending on the response.

@musicinmybrain
Copy link
Contributor Author

oklog/ulid#111

@musicinmybrain
Copy link
Contributor Author

Based on discussion in oklog/ulid#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 #13. Feel free to close this issue if no change is planned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant