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

The downloaded gitstatusd binary should be saved to an arch specific name #10

Closed
krader1961 opened this issue Jun 4, 2020 · 5 comments

Comments

@krader1961
Copy link
Contributor

I sync my home directory (most of if it, anyway) to my other systems. The problem is that this elvish module saves the appropriate downloaded binary to ~/.elvish/package-data/gitstatusd. This causes problems if that directory is shared by platforms that have different operating systems (such as macOS and Linux) or architectures (such as ppc and x86_64). The downloaded binary should include the OS and architecture in the filename it is saved to. Note that this is easier, and cheaper, to do now that we have $platform:os and $platform:arch.

@href
Copy link
Owner

href commented Jun 4, 2020

I can sympathise with this, since I do the same. Though because I have a homogenous set of systems it didn't occur to me.

I think it makes sense to implement this. It's good timing too, because I have to rewrite the way binaries are updated due to romkatv/gitstatus#33.

I kind of know what to do already, but haven't gotten around to it yet. For now, thanks for your report!

@krader1961
Copy link
Contributor Author

That the author of gitstatusd doesn't consider backward compatibility with old clients important makes me do a /facepalm. At least they recognize that when they say:

The output format of gitstatusd is too primitive for any kind of backward compatibility...

What makes me sad is that the gitstatusd author doesn't recognize that even using its primitive binary format there is no reason backward compatibility can't be maintained. At least across most updates to that tool. Even worse is they think that simply forcing everyone to update in lockstep with their project updates, as discussed in comment, is an acceptable strategy.

@href
Copy link
Owner

href commented Jun 6, 2020

I pushed an update with 7487ad9 that gets the latest gitstatus release, using separate paths per OS and arch. Please have a look and let me know if it works for you (it does for me).

@krader1961
Copy link
Contributor Author

Works for me, @href. Thanks for the fix.

@href
Copy link
Owner

href commented Jun 7, 2020

You‘re welcome. Closing this issue.

@href href closed this as completed Jun 7, 2020
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

2 participants