I’d only add that indeed we need to make sure we standardise to utf-8 not only for the authenticator but also for all language bindings, at the moment our safe_app_nodejs binding is using Buffer’s to pass the data to the native lib so if you @riddim happen to be able to read some data (like MutableData entries) with your python binding please let us know as it would be good to confirm the encoding is correct.
3 Likes
I am afraid I can’t say when that will happen but as soon as I can retrieve data from safe I’ll check it out and let you know =)
4 Likes
That’s fine @riddim, thanks a lot, I agree you raised a very good point here to consider and review!
4 Likes
Hey riddim, some super nice work.
Is there any way I can contribute to your efforts? I am quite experienced in Python/C and have a little time. A python safenet package before launch would be a great help to the community and project.
5 Likes
heyhey @DASK
thank you very much for the offer! very very cool - i would love to get others involved too
(since i have a lot to do at work since a couple of days and i will be very busy until ~end of this month … i probably won’t be able to work too much on the python bindings now)
I just now created a dev branch of my tests/findings/concept stuff and reorganized everything a bit … that it doesn’t just fly around how it happened to appear in my mind … https://github.com/rid-dim/pySafe/tree/dev
there are compiled binaries [64 bit debian based linux] (for the alpha2 network) in the corresponding folder … but the point where i am a bit stuck is exactly that…
Let me outline my plan a bit:
- main tasks right now are:
– finding out how to connect to the ‘real network’ … the crust config seems necessary but i have no clue how to use it correctly/where to put it … or maybe the name still is wrong … it just doesn’t work atm for me
– preparing the parser that takes the function definitions as extracted from the gcc compilation output and printing function definitions with local callback functions … but i’m afraid that one might be some more work there …
– when the C headers get exported fully we can utilize those and generate all the datatype definitions and raw function definitions from those … then we’ll have a wireframe for our Authenticator and App Classes in python. Cooperating then will be much easier I think because then everybody can just pick a method and implement a default behaviour or add new methods that combine others to very comfortable one-liners
But what really would be super helpful as a start and right now @DASK would be finding out how to make the authenticator connect to the real alpha2 network.
I stole a crust.config from the browser and named it as the stem-function suggested (and verified my ip is whitelisted by starting up peruse and connecting to safe) but somehow i don’t manage to get a connection … (you can see my ‘progress’ in the linked notebook)… Imo it’s a pretty basic thing that should be known when we want to release the first functions/a simple Python authenticator …
if you are not on linux you’ll need to compile your own client_lib_binaries … but at least on linux it’s not a big deal … just cloning the repo, installing rust and typing into a command prompt ‘cargo build’
ps: of course I don’t know if you do work with jupyter Notebooks… That’s just the way I do it and how it’s easiest for me… But I’m open to learn using other tools too if you think there are better options here =)
5 Likes
Thanks! And sounds like an ideal place to start. I’ll clone the repository and have a hack at it. Have both linux and Windows machines, so I’ll start on the linux one. I typically work with either pycharm or notepad++, depending on project scope, but Jupyter also works.
2 Likes
=) supercool!
(I do like to use anaconda environments - there is jupyter included and everything works out of the box - the only annoying thing is that I need to use chromium for using jupyter because the copying/inserting by clicking the middle button on the mouse and some shortcuts don’t (at least didn’t) work with Firefox…)
I found some moments to think and do some small tests and will probably push a prototype to generate the method definitions with doc string and everything later =)
So i think as soon as we figured the crust config thing out and have the c headers the fun part can really start
okay - here we go - i implemented a (again not very beautiful but) simple (and modular) printer for the suggested structure
i did copy the output into a code cell (with ctrl,shift,- they can be split [sidenote for the interested reader])
in case of a FfiResult* being returned the default behaviour is to call the defaultFfiResult-Method which just prints the result in case of the concept demo
if you have any ideas/suggestions i appreciate all feedback and of course just editing and opening pull requests on github will work perfect too (at least i guess so xD … it’s not like i did this before …)
1 Like
My understanding is that it should be named in the same fashion as the executable (@nbaksalyar maybe you can correct me if i’m wrong here).
The libs themselves though, will create crust/routing/config files if they are not present. So, as long as you’re able to init the libs, @riddim, you should see these files being created.
When I had to locate them for osx/electron after moving the libs to a different electron process, a wee find . -name "*.crust.config" in the app folder got me their name/location, so you could try something similar.
1 Like
Sorry @DASK i am just a very impatient person :-\ … i followed the hint of @joshuef and found a crust.config-file not created by me in the anaconda environment folder ( /home/myUser/anaconda3/envs/py34/bin/python3.crust.config ) and seem to have got in touch with the real safe Network from python =)
To be sure it’s not mock routing I tried to create a random additional account and got an error (as you would expect from the real network) =)
… now … you don’t happen to know how we could create/edit this file from python automatically? 
(since it’s the ‘base folder of my python environment’ this makes absolutely sense … as a place corresponding to ‘where the executable’ is with a compiled exe file …)
I never made any Python modules installable from pip but I think there is where such a packet would need to install/update the correct config file…
Ps: so now we could use some fully defined headers to derive the definitions for our cffi declarations 
but I’m on vacation for a bit more than a week in a week… So I won’t be able to do much within the next days anyway =) I guess we give maidsafe now some time to get the c headers finished and benefit from their hard work then by having a first version of the api in Python automatically then
… Doing some research on how we can distribute the api the best way is probably the most reasonable way to use our time now
5 Likes
Nice! I’ve been caught up with sick little kids. Very demanding on time and energy. I’ve only managed to review and understand your efforts so far. You now seem to have cracked the hard bit. With @joshuef’s tip, I’ve just made it connect on my machine now anyway.
I’ve done a bunch of installable modules (pip, wheel, etc.) and will have a chance to add the boilerplate for that on Friday. Autogenerating the file is trivial, but I’ll have to do a bit more research to figure out if one of the methods for runtime manipulation of the python path / environment, or something else, is suitable for getting the file correctly located as far as the libs are concerned. Much cleaner if it can be grouped with the actual app, or better, specified location, rather than in the core python environment. Worst case, locating the bin directory of the relevant python.exe is doable, but thinking further down the road, e.g. if we want to say include the python safe module into a compiled daemon or something along those lines, something more flexible is needed.
For usefulness, the final workflow/api for a user/new dev needs to look more like:
import PySafe
PySafe.custom_config(options)
connection = PySafe.Connection(credentials)
connection.do_stuff()
3 Likes
I hope they are/will get better now/soon! All good - family is more important than this!
100% agree that sounds like an excellent plan and like the right workflow =)
Awesome! Okay than I’ll focus on some private stuff that I should do the next couple of days and am curious about the plan for distribution 
we seem to have both managed to connect to safe pretty much the same moment xD glad you’re on board! 
1 Like
@riddim, you should be able to use auth_set_additional_search_path function to set the path where you want your crust config file to be looked up, I think it will still need to be named as Josh said but at least you can place it in any other folder you like.
2 Likes
I think on Linux it should probably go in ~/.pysafe
1 Like
In this case you may want to allow the python app developer to set a different path by calling a function you expose form your python API, or by using an env var, or as an argument of any of the API it’s exposing already, but the default path is probably better to leave it as is, since each app may want to use different config files which they provide with the package itself rather than reading it from the user’s .pysafe…?.. E.g. in Beaker we allow the user to set SAFE_CONFIG_PATH env var to load it from another path.
Hm? But when we leave the config in the Python bin directory it will be ‘an old one’ when using the wrong Python environment, needs to be changed in every Python environment you use and if devs/users want to set it specifically for their app they need to locate it somewhere else anyway (since the whole Python environment looks to this place - no matter what script is running at that point in time)
So I do like ~/.pySafe as default to be honest - like this I can change the Python environment and everything behaves like it always does and it’s more accessible than the specific root folder of each environment…
Or are I missing something now?
The scenario I’m thinking of it’s if I create two different apps using your python binding library/module, I then create a zip file for each of them where I include everything needed to run the app, including the crust config file (let’s say they use different configs), and my python app as an executable.
I then share them with you and ask you to unzip them and run them individually. Since I didn’t set any path for the configs it will take the default (the one you set as default in you module, otherwise the one set by safe_app lib as default, which is the executable’s path).
What I (as a developer of those apps) would expect is that the configs are loaded from the corresponding folders where you unzipped them and run them.
I’m not a python expert but wouldn’t it be this the case if you shared your python app as an executable, i.e. the exec path is not the python interpreter’s path but your app’s path?
2 Likes
Hmhmm - I’ll bundle it later with pyinstaller and look into the consequences
Of course that should work as well 
but since bundling Python to an executable is kind of above the basic levels of Python I could imagine that one needs e.g. To do
PySafe.custom_config(path=None)
To make it located as the lib wants
I personally would think the home folder version is less of a hassle for the other cases where you want to use different scripts you run and where it might be necessary to switch environments - but of course that could just be how it would affect my life - maybe one of the others has an opinion here too…?
1 Like