dashhive / bls

MIT License
0 stars 0 forks source link

v1 Feedback: Release and CLI options #6

Closed coolaj86 closed 1 year ago

coolaj86 commented 1 year ago
wmerfalen commented 1 year ago

I would estimate 10 Dash for all of these

coolaj86 commented 1 year ago

Re: forking

If it makes sense to use the code as a vendored dependency, great.

If it's such a small amount of code that it makes more sense to copy the useful bits on their own, great.

But I don't want all the cruft that we don't need (js, python, etc, etc) cluttering up what this tool is. If the best way to get rid of that is just delete it, great.

wmerfalen commented 1 year ago
* [ ]  Can we make this a repo that _uses_ the bls-signature library rather than _forking_ it?

That won't be a trivial feature to implement. I don't have an estimate on how long that would take to figure out. It would involve building the original bls-signatures code as a dynamic library then linking to our code. Right now, we have everything building in a static way, which is how we have all the binaries working right out of the box with no need to install anything extra.

wmerfalen commented 1 year ago
* [x]  publish to github releases in .tar.gz with exec bit set

https://github.com/dashhive/bls/releases/tag/v1.0.0

* [ ]  add to webi (probably identical to GoReleaser builds, such as keypairs) see the following:

https://github.com/webinstall/webi-installers/pull/520

wmerfalen commented 1 year ago

But I don't want all the cruft that we don't need (js, python, etc, etc) cluttering up what this tool is. If the best way to get rid of that is just delete it, great.

The binary that gets created doesn't have js or python bindings.

coolaj86 commented 1 year ago

It would involve building the original bls-signatures code as a dynamic library then linking to our code. Right now, we have everything building in a static way

But couldn't we just git clone the original into a ./vendor/bls-signatures and then import it from that directory and still build it statically?

The binary that gets created doesn't have js or python bindings.

But the repo does. The repo should be focused just on the CLI tool, not carry the legacy of other tools that aren't related to the tasks for which this is created.

wmerfalen commented 1 year ago

How about this.. I can write a script that checks out the exact version we're using when I forked it, then applies a diff patch to the necessary files and then from there it compiles it as normal?

coolaj86 commented 1 year ago

No. This is not a fork.

This is a tool that happens to use some code from another tool. It's a separate project with separate goals.

If there's code that we're likely going to need to track, then we should vendor or dependency it.

Dash already suffers from forkititus.

When you're creating a different project with different goals, code re-use is no longer "just a fork". The heritage of the legacy code goes in the acknowledgments and maybe the git history, not the new codebase.

coolaj86 commented 1 year ago

Closing round 1 of feedback as complete. Additional changes can go into round 2.