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 #111

Closed
musicinmybrain opened this issue Jan 31, 2024 · 8 comments
Closed

Multiple conflicting command-line tools called ulid exist #111

musicinmybrain opened this issue Jan 31, 2024 · 8 comments

Comments

@musicinmybrain
Copy link

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
Copy link
Author

mdomke/python-ulid#14

@peterbourgon
Copy link
Member

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
Copy link
Member

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

@musicinmybrain
Copy link
Author

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
Copy link
Author

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

mdomke/python-ulid#15

@peterbourgon
Copy link
Member

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

mdomke/python-ulid#15

🙇

@musicinmybrain
Copy link
Author

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
Copy link

mdomke commented Mar 19, 2024

@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

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

3 participants