okay … something else slightly strange … I see a file_cost method, file_download and file_download_public but there’s no file_upload (?) … I tried the dir_upload and provided a file path instead a directory … which did result in
RuntimeError: Failed to upload directory: Failed to upload file
so I assume it may have worked - but not entirely sure … In any case it’s rather confusing and maybe there should be a file_upload method that just redirects to the other method?
Hi riddim!
I’m Victor, I’m new on this project, just arrived! I’m here about QA, and have background as firmware engineer & QA in this field and other fields.
I have a lot to catch up (Autonomi is big) but I’m here to help, so now you know I exist you can ping me!
I’m digging the errors you have
Just a quick question, you are using the pre release version of Python Client 0.4.0rc3 ? Or the previous version 0.3.61 ?
Some of your errors seem new to me (e.g TypeError: argument 'addr': 'str' object cannot be converted to 'XorName')
I’m experiencing the same with the pre release but it was not the case with the previous version
Hey Victor! Nice to meet you!
Yes previous version took strings more often - I think I saw a merged pr that contains additional exports for the missing types but there’s no new release containing it
That’s right, there should be a release very soon. We are releasing in step with rust crate versioning so just waiting on the release cycle in house to push the cargo.toml version number then we can go.
I’m not sure why dir_upload failed for you, I just tested it and it worked for me.
We have file_content_upload (and its public variant) though! The reason these have _content_ in their name is that it does not upload metadata or its filename. So dir_upload is a good choice here if you want to upload it as an archive, which includes this metadata.
yes - probably i was simply too cheap and just hat 10Cent in ETH on that address
i had failing uploads from vps too and sold 3ANT to top it up 
after that it worked again …
sorry … i should have reported that and will try again from python (uhm … but i’ve seen failing quotes via wifi … now on ethernet… we’ll see)
EDIT:
guess it’s my crappy internet/router that is the issue … as you can see it takes 3 minutes something to fail …
Hmm, and the error is not helpful at all. That’s definitely something we should look at.
My only thought has been that we can report the error from Rust as a string with all inner errors. This can be done with eyre (example here). We also use eyre for our CLI to report errors on the command line.
to become a clear error (quote/payment/chunkverification/…) would be very nice indeed … to not guess at which step the error is and if i am out of ANT / ETH or dropped out of my wifi/forgot to plug in the ethernet cable
i think just showing the rust error as string would be perfect for starters; no need to re-define all errors on python side …
Out of pure ignorance and luck, and partly due to starting with that approach because it’s sensible in an app (awe), I’m currently only using eyre to report errors as text throughout dweb-lib.
Where the Autonomi APIs insist on proper 
error types l convert them to text which is much more useful along with my copious debugging output to the terminal.
I agonise over that now and again because it’s not how your supposed to do it in idiomatic Rust, so it’s good to see the approach isn’t completely batshit stupid! 
One day I will regret it though, I’m sure.
pointer working - created a pointer that points to your pic - got that back from the network via the pointer.
I know the count is again more of an internal state; but that state can be of interest for app devs too (to know if the pointer has only been created and was never re-written … or somehow managed to reach max_count …) so exposing that state would be nice @bzee
for GraphEntries I don’t see how I could create them from python… there’s no constructors
and the client doesn’t have a create function but only a put function (which is useless because of the missing constructor for GraphEntries) so I seem to only be able to read GraphEntries from python (?)
oh - and maybe some additional point for scratchpad …
there’s a scratchpad_get_from_public_key - but then there is literally not a singled method I could call on it …
same when I just use the client.scratchpad_get
The Pointer counter is exposed in Rust so I’m sure it’s coming.
GraphEntry has a constructor but you have to do a lot of intricate low level work to use them. I would never have figured out how if Anselme hadn’t built exactly what I needed (Registers) in order to implement dweb::trove::History using them.
I suspect we’ll need to build a useful set of things in Rust, like Registers and History, and then expose those as APIs because GraphEntry is like hand coding assembly language and few will be doing that.
but what if I want to create a simple mint to showcase the possibility of erc20-like DAG token on top of autonomi? 
…
i want that GraphEntry … it’s one of the fundamental datatypes … not exposing it properly would be like saying “you don’t need int and float … just put your numbers in pandas Dataframes - they’re more powerful anyway”
a simple mailing system could as well be built on top of graphEntries … but only if I have access to them … it’s essential …
I’m not saying they shouldn’t expose it! Everything in Rust API should be exposed IMO.
Will the gas limit be exposed to the python api? (ideally there would be a way to review before just sending out txs…) with the right app design even the current failure rate for uploads wouldn’t be a real deal breaker… If there wasn’t the real and great danger of wallet drain…
Ultimately the python API (and other languages too) will match the rust API 100% and have all the features high and low level. We are currently in the process of making this a reality.
This would be an excellent use case of GraphEntries! They are in fact very much inspired from our Spends which are the foundation of our Native currency!
As @happybeing points out, they are quite low level and you need to do everything manually. One good thing to know is that you can use all the fields in the GraphEntry freely the Network only cares about the authenticity of the signature over the content!
Yes it’s in the plan to make the Python API a perfect clone of Rust API, there is just some inertia as Rust is the main API and Python is bind to it !
As Anselme was saying, we are working on it !
It’s always nice from you and everyone to have your feedbacks ! Feel free to ping me as well about Python Client
