Closed coolaj86 closed 1 year ago
[ ] publish to github releases in .tar.gz as
bls
with exec bit set
[ ]
-V, --version
[ ] Use
-s, --short
convention
- nix DOS-style flags
[ ] error on unknown flags:
error '--unrecognized' is not a recognized flag
+ help/usage message[ ] add to webi (probably identical to GoReleaser builds, such as keypairs) see the following:
[ ] Can we make this a repo that uses the bls-signature library rather than forking it?
I would estimate 10 Dash for all of these
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.
* [ ] 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.
* [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:
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.
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.
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?
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.
Closing round 1 of feedback as complete. Additional changes can go into round 2.
bls
-s, --short
conventionerror '--unrecognized' is not a recognized flag
+ help/usage message-V, --version
should output version info