Refactor into jcli-lib crate #3216

filip-dulic-bloxico · 2021-04-13T17:23:23Z

This is the beginning step for refactoring the jcli-lib crate out of the
jcli binary crate.

This is the beginning step for refactoring the jcli-lib crate from the jcli binary crate. This is the starting commit for #3172

…manifest

This module really doesn't make sense to have if the 'structopt' feature is disabled. The gated attributes can be safely removed as long as the entire module is gated. I'm leaving the gated attributes in place, until the API is better defined.

jcli-lib/src/address.rs

eugene-babichenko

The idea itself is good, BUT. IMO what is being done currently defies the whole purpose of moving functionality into the library. This library includes things that should be there (argument parsing) since they are going to be used only in jcli and this is not what I would call a good API either.

See my review comment below: instead of moving everything into the library we should start to gradually separate the functionality, that is needed to be shared to other apps.

I don't even mind not having the full functionality of jcli in the library in the first version, I understand this is a gigantic piece of work. This is perfectly fine as long as it is usable in other apps.

That said, instead of doing what we have done currently I would suggest to:

Identify the current clients of this library (excluding jcli).
Design a proper API that would not bring in the whole dependency tree of jcli. Given the nature of this library I assume that this would be just a bunch functions.

eugene-babichenko · 2021-04-20T06:51:11Z

jcli-lib/build.rs

@@ -0,0 +1,19 @@
+fn main() {


This is not needed for the library actually. We should be pretty much happy with what Cargo.toml provides.

eugene-babichenko · 2021-04-20T06:55:02Z

jcli-lib/src/address.rs

 use structopt::StructOpt;
 use thiserror::Error;

-#[derive(StructOpt)]
-#[structopt(name = "address", rename_all = "kebab-case")]
+#[cfg_attr(


I would oppose that. Instead just "move the functionality to the library and optional command parser" we should implement an API that is intended for library users. By this I mean that the current approach, that is initially intended for "parse arguments and run a command" is not suitable here. Most commands could (and should) be made into functions receiving several arguments.

Let's reserve argument parsing for the actual CLI binary and think of a better approach here.

Actually, argument parsing could be reused too. Even inside jcli itself we have some duplicated code. Also some tools could reuse some of that code (it is being used for a tool now on catalyst-toolbox).

Even inside jcli itself we have some duplicated code

This is the problem of a client, not the problem of a library. ;)

Also some tools could reuse some of that code

Need to look at the amount.

This is the problem of a client, not the problem of a library

In this case, it is both.

The library could implement things like parsing common argument formats. Probably not the options and subcommand structures though, these should be defined in the CLI tool.

danielSanchezQ · 2021-04-20T07:41:31Z

I don't even mind not having the full functionality of jcli in the library in the first version, I understand this is a gigantic piece of work. This is perfectly fine as long as it is usable in other apps.

+1

That said, instead of doing what we have done currently I would suggest to:

* Identify the current clients of this library (excluding **jcli**).

* Design a proper API that would not bring in the whole dependency tree of `jcli`. Given the nature of this library I assume that this would be just a bunch functions.

IMO we could make every (needed) module could have an IO part (args parsing that can be reusable, some of the modules already had it, but they were private), and extract and refactor the exec methods into functions

eugene-babichenko · 2021-04-20T08:40:48Z

IMO we could make every (needed) module could have an IO part (args parsing that can be reusable, some of the modules already had it, but they were private), and extract and refactor the exec methods into functions

Sounds about right. I am still a bit skeptical about sharing structopt definitions, but if we really need them this is a cleaner approach. At least we can put all of them in a feature-gated module instead of playing around with cfg_attr which certainly doesn't contribute to readability.

danielSanchezQ · 2021-04-21T08:34:09Z

I let it as a draft for now, while we discuss what we will finally do.

mzabaluev · 2021-05-18T06:54:26Z

jcli is currently used as a library in catalyst-toolbox, so it would make sense to check what is it used for and provide an API.

minikin · 2022-04-04T08:28:47Z

@filip-dulic-bloxico Closing it. Feel free to reopen if we really need it.

Add new jcli-lib crate to workspace

a28223f

This is the beginning step for refactoring the jcli-lib crate from the jcli binary crate. This is the starting commit for #3172

filip-dulic-bloxico force-pushed the jcli-lib-refactor branch from 2f5f5a9 to a28223f Compare April 13, 2021 17:26

filip-dulic-bloxico added 4 commits April 13, 2021 14:37

transfer the same dependencies from jcli to jcli-lib

d002b33

bulk transfer of jcli_lib code into jcli-lib crate

232d99f

refactor main library modules, transfer to new crate

e445722

set jcli-lib as a dependency of jcli

07fbb0c

filip-dulic-bloxico linked an issue Apr 13, 2021 that may be closed by this pull request

Jcli lib refactor #3172

Open

5 tasks

filip-dulic-bloxico changed the title ~~Refactor jcli-lib crate into workspace~~ Refactor into jcli-lib crate Apr 13, 2021

filip-dulic-bloxico added 3 commits April 13, 2021 15:33

correct imports in new jcli-lib

502f473

copy build.rs from jcli crate

be60ecb

remove unused dependencies from jcli

b5235e9

filip-dulic-bloxico force-pushed the jcli-lib-refactor branch from a3179ba to b5235e9 Compare April 13, 2021 20:33

filip-dulic-bloxico added 12 commits April 14, 2021 13:56

make structopt an optional feature, add to default features in Cargo …

92f5a70

…manifest

feature gate structopt attributes for jcli_lib::address

49c52d8

feature gate structopt attributes for jcli_lib::block

422f282

feature gate structopt attributes for jcli_lib::certificate::*

30fdb1f

feature gate structopt attributes for jcli_lib::debug::*

4f21efd

feature gate structopt attributes for jcli_lib::key

6525177

feature gate structopt attributes for jcli_lib::rest::*

6584dd4

feature gate structopt attributes for jcli_lib::transaction::*

a0bce01

feature gate structopt attributes for jcli_lib::utils::*

5d2f1b4

feature gate structopt attributes for jcli_lib::vote::*

1fdb6b7

feature gate structopt attributes for top-level lib.rs

48ad2d8

danielSanchezQ reviewed Apr 15, 2021

View reviewed changes

jcli-lib/src/address.rs Show resolved Hide resolved

filip-dulic-bloxico self-assigned this Apr 15, 2021

filip-dulic-bloxico added 4 commits April 15, 2021 15:27

feature gate auto_complete module

0c0a6bb

add top-level docstrings to modules in crate

247030b

more doc strings for modules and public types

004405f

make crate::rest::v0 module public

192d45f

filip-dulic-bloxico marked this pull request as ready for review April 19, 2021 18:21

remove duplicate Seed structs, make Seed public for library

d57f892

eugene-babichenko reviewed Apr 20, 2021

View reviewed changes

danielSanchezQ mentioned this pull request Apr 20, 2021

Jcli make transaction #3230

Merged

danielSanchezQ marked this pull request as draft April 21, 2021 08:33

danielSanchezQ added the DO NOT MERGE not to be merged until something else is done label Apr 22, 2021

minikin closed this Apr 4, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor into jcli-lib crate #3216

Refactor into jcli-lib crate #3216

filip-dulic-bloxico commented Apr 13, 2021

eugene-babichenko left a comment

eugene-babichenko Apr 20, 2021

eugene-babichenko Apr 20, 2021

danielSanchezQ Apr 20, 2021

eugene-babichenko Apr 20, 2021

danielSanchezQ Apr 20, 2021

mzabaluev May 18, 2021

danielSanchezQ commented Apr 20, 2021

eugene-babichenko commented Apr 20, 2021

danielSanchezQ commented Apr 21, 2021

mzabaluev commented May 18, 2021

minikin commented Apr 4, 2022

Refactor into jcli-lib crate #3216

Refactor into jcli-lib crate #3216

Conversation

filip-dulic-bloxico commented Apr 13, 2021

eugene-babichenko left a comment

Choose a reason for hiding this comment

eugene-babichenko Apr 20, 2021

Choose a reason for hiding this comment

eugene-babichenko Apr 20, 2021

Choose a reason for hiding this comment

danielSanchezQ Apr 20, 2021

Choose a reason for hiding this comment

eugene-babichenko Apr 20, 2021

Choose a reason for hiding this comment

danielSanchezQ Apr 20, 2021

Choose a reason for hiding this comment

mzabaluev May 18, 2021

Choose a reason for hiding this comment

danielSanchezQ commented Apr 20, 2021

eugene-babichenko commented Apr 20, 2021

danielSanchezQ commented Apr 21, 2021

mzabaluev commented May 18, 2021

minikin commented Apr 4, 2022