Adding ipfs trait#10
Conversation
I am creating this new branch and moving my changes over, so I don't have to deal commit merging issues
We can connect! YAY
I am creating this new branch and moving my changes over, so I don't have to deal commit merging issues
We can connect! YAY
|
I think its ready for review again but I don't dont think anyone is going to be able to review it until the 3rd |
the changes I made to to my fork were merged with master
bgins
left a comment
There was a problem hiding this comment.
Made a few copy edit suggestions and comments on coding style while doing a first pass through the code.
Co-authored-by: Brian Ginsburg <7957636+bgins@users.noreply.github.com> Signed-off-by: Savannah Jackson <savannah@fission.codes>
Co-authored-by: Brian Ginsburg <7957636+bgins@users.noreply.github.com> Signed-off-by: Savannah Jackson <savannah@fission.codes>
Co-authored-by: Brian Ginsburg <7957636+bgins@users.noreply.github.com> Signed-off-by: Savannah Jackson <savannah@fission.codes>
Co-authored-by: Brian Ginsburg <7957636+bgins@users.noreply.github.com> Signed-off-by: Savannah Jackson <savannah@fission.codes>
Co-authored-by: Brian Ginsburg <7957636+bgins@users.noreply.github.com> Signed-off-by: Savannah Jackson <savannah@fission.codes>
Co-authored-by: Brian Ginsburg <7957636+bgins@users.noreply.github.com> Signed-off-by: Savannah Jackson <savannah@fission.codes>
bgins
left a comment
There was a problem hiding this comment.
I was researching how other projects organize test examples. What would you think about renaming test-dir to tests and then having a subdirectory named data where the test examples go?
It looks like that is how ripgrep has things organized: https://github.com/BurntSushi/ripgrep/tree/master/tests/data
| // for peer in PEER_ADDRS { | ||
| // block_on(ipfs.connect_to(peer)).unwrap(); | ||
| // println!("Connected to peer! {}", peer); | ||
| // } |
There was a problem hiding this comment.
Oh actually, this is in a test. Verbose mode doesn't matter here. 😅
I'd say lets keep the code or remove it depending on the feedback we want when running the test.
zeeshanlakhani
left a comment
There was a problem hiding this comment.
Adding a few bit of comments/questions now @BoisterousCoder. I'll go through this more.
| async fn set_config(&self, property:&str, val:&Value) -> Result<()>; | ||
| /// This method returns the value a property in the IPFS config | ||
| /// | ||
| /// Ex. `ipfs.get_config("Datastore.StorageMax")` |
There was a problem hiding this comment.
minor: There are specific standards for Rust "example" documentation: https://doc.rust-lang.org/beta/rust-by-example/meta/doc.html.
There was a problem hiding this comment.
So, doc tests will fail if I attempt to do them properly because it gets a connection refused error. I can either remove those examples completely, find a way to do the doc tests without having to run them when cargo test is run, or leave them how they are.
There was a problem hiding this comment.
fwiw doctests can be made ignore run with ignore keyword after the three backticks that assume "run rust"
If one wants to gate the doctest to make the ignore based on e.g. cfg() you can use cfg_attr like this:
https://github.com/dalek-cryptography/ed25519-dalek/blob/release/2.0/src/lib.rs#L21-22
Probably should improve that rust-by-example doc to include those keywords and how to use w/ attr
That also ponders the question if there is / could be a worthwhile mock like what httpmock provides in http world - or a record/replay artifact a'la fashion of insta.
There was a problem hiding this comment.
Changed it to be an ignored doc test
| use crate::utils::file_management; | ||
|
|
||
|
|
||
| fn run_ipfs_test<T>(test: T) -> () |
There was a problem hiding this comment.
We should add a TODO on testing here, as most of this will be redone separately, as to not have to rely on running ipfs directly. Though, we should move all of these into an integration test setup, as in the template for example.
| use colored::Colorize; | ||
| use walkdir::WalkDir; | ||
|
|
||
| pub fn get_files_in(dir:&str) -> Result<HashMap<String, Vec<u8>>> { |
There was a problem hiding this comment.
I see this in the test, but do we need this anymore since we moved to the rust-api-client lib? get_files_in is done for add, right, but their add_path should already do the walking + adding work, right? https://github.com/ferristseng/rust-ipfs-api/blob/master/ipfs-api-prelude/src/api.rs#L205
There was a problem hiding this comment.
I use that function in the testing so I can double check that all files have been uploaded. I think it won't be needed once we move to wire mock. However the current way I handle checking that all the files got uploaded is looking at the all the file and folder that should have been uploaded and checking that they are included in the return from the ipfs node.
| /// Ipfs often returns json with a single property with the value being an array. | ||
| /// This function simply takes the array in that property and turns it into a vector that can be used in rust. | ||
| /// It will return an error result if the json is not formatted in this way. | ||
| pub fn value_to_vec<A>(json:&Value, index:&str) -> Result<Vec<A>> |
|
@bgins Those sub-directories are there to test that you can upload sub-directories and what's inside of them |
Ah ok, I missed that. Makes sense to keep them then. 👌 |
zeeshanlakhani
left a comment
There was a problem hiding this comment.
@BoisterousCoder Thanks for making all the changes, and this is in good shape! However, personally, I'd probably remove the dead code (as we can revisit things from utils at another point) and remove the tests using this code.
Yep, this seems like the right call. It will make the code base cleaner and easier to read. We may have use for some of the dead code in the future. If we do, we can pull it up when we need it. I'll keep this branch around for future reference. |
Okay, dead code removed |
| use colored::Colorize; | ||
| use walkdir::WalkDir; | ||
|
|
||
| pub fn get_files_in(dir: &str) -> Result<HashMap<String, Vec<u8>>> { |
There was a problem hiding this comment.
@BoisterousCoder minor: but is this needed still? I think the ipfs client add, adds dirs?


Description
This pull request implement an implantation for ipfs so code can later the call the following features:
Add ability to do swarm disconnectImplicit disconnect when daemon closesAdd ability to do bootstap addThis is covered by the config commandLink to issue
closes #7
Testing
There are intregration test that are located in
./ipfs/tests.rs. Just docargo testto run them andcargo test -- --nocaptureif you need to see the console log. These test should hit the entire code. Just note these tests reference the fission production ipfs nodes and a couple of the tests upload files. Also you will need to have ipfs in your PATH as the daemon is launched using theipfs daemoncommand.Type of change