-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
using b2 command line tool as a library #4
Comments
Making a library or class for programmatic access to the B2 APIs needs to be done, and if you'd like to help out with that, it would be great. We currently have a Java class that we use for most of our testing. Having a Python interface as well would be helpful. This is what the Java interface looks like:
|
This is almost exactly how I imagined it should look like. How do you want to do it? Should make a big pull request which would then be updated as I rewrite the core and front methods gradually, while you can observe / review the process and then after all review comments are applied, it will be merged? |
That sounds great. I look forward to working with you on it. |
BTW, in the Java code we have another layer on top of the B2Api that keep track of bucket IDs, and all of the auth tokens. It's not quite what the b2 command-line program wants, because the command-line has its own way of managing and persisting the auth tokens. Might be worth keeping in mind for the future, as another possible layer in the Python code.
|
One more thing. Currently there are some options like Can I fix it? Is it ok if I do both of those in one go? |
Let me go ahead and to it. I just changed the syntax of the command line yesterday, and we haven't published the new version on the web site yet. If I make the change now, it's just one thing to put in the release notes.
|
Ok, another question then. Do we still want to keep everything in one file? |
I'd like to stick with one file, unless it becomes a big problem. We like having a single file to download from the web site that is the command-line tool. At some point it will get big enough, or complicated enough, that it's ungainly, but it would be nice if that's off in the future. |
Can we make it so that the sources are spread into many files, which are then magically put into one file during a build process, so that we can have both a tidy project and downloadable single file solution for people that just need it to work? That is for the future though, as you say. I'll stick with the one file for now. |
The other option for easy installation, which AWS uses for its command-line tool, is to make it available via pip. |
Ok. I'll start working on #4 this weekend. |
@bwbeach do you need to keep compatibility with Python 2.6? |
No. Python 2.7 is fine.
|
@bwbeach: Be aware that Enterprise Linux 6 (Red Hat, CentOS, SciLin, etc.) do not include python 2.7 support in the standard RPM repos. |
Well that's annoying.
|
Tell me about it. I support a few customers that have several thousand EL6-based systems and they're unlikely to be upgrading any of them until at least mid-2016. Their enterprise IA groups are waiting on SCAP-related guidance for EL7 to get finalized before allowing migrations of production services to EL7. Python 2.7 exists in the SCL repositories, but most of my customers haven't them approved for production. Enterprise Linux customers tend to be cautious with production systems. |
Thanks for the useful info. Sounds like we should stick with supporting 2.6. :-/
|
@ferricoxide actually RHEL6 is exactly why I asked the question in the first place. Thank you for helping to clear it up. |
Yes. It's time to close this one. Thanks for all the work! |
How stable is the API? Can I use it in an application? Edit: I ask because there are currently no generated docs anywhere. I'm relying on reading the source code and referring to the Java spec above. |
Don't rely on the Java spec, we didn't follow it strictly. I don't think the API has changed in an incompatible way even once since it was born, so the stability is kind of infinite. In my opinion using the api than doing things on your own - if b2 cloud API will change, we will compensate for it with our code, so that you don't have to. As it is a rare event that we can actually talk, I'd like to ask what your usage will be. If you share that, we could design future features with taking your interest into account. As for the documentation, I think nobody thought about it. Do you have any suggestion on what the docs should be like (an example from some other project perhaps)? |
As a follow up: I think I'll be just writing some request calls rather than using this library for now due to the lack of documentation. Furthermore, I think it would be beneficial for this library to have some simple unittests and maybe a refactor (library api directory + cmd line interface file) so the code is not 2kLoC all in one file. This would allow me to more easily inspect the library's implementation, by looking through the documentation and drilling down to the implementation by looking through directory listings rather than grepping through a single file. It is also somewhat difficult to find enough time to review a 2kLoC file. A suggested library structure might be something like (obviously would require a little bit more work):
Usually python projects are documented via Sphinx. Usually it consts of a tutorial sort like page to demo/sell the project and then the API references for people active working on the project who needs to know about all the object. A good example may be found here: http://basho.github.io/riak-python-client/index.html Unfortunately the example above moved its tutorial to a separate page, but it links that in the top of main page.
My usage case right now is extremely straightforward as I'm currently evaluating B2. Once a day, I will be generating a report of some sort and uploading a file on to B2. It then takes the link to the file and send it out over email. From as far as I can tell, I would need to:
Then I should be able to construct the link to email. I foresee be doing other things with B2, but that probably will not be relying on a Python client. I'll have to see about that.
I definitely have this concern as well. Furthermore it is possible to use a library such that I can hide details about However, given the issues I have outlined above with regarding documentation and the difficulty of inspecting the code and the tasks I have in mind is very straightforward as outlined, I'll skip out on the library approach for now. I'll keep following the project and definitely will re-evaluate (or maybe contribute, depending on the needs) this project in the future. |
I agree about having unit tests and refactoring into multiple source files. We were waiting for pip install before going to multiple files; that's done now, so the restructuring can proceed. I also agree about Sphinx docs. They need to be written. Hoping to get that done relatively soon. |
I would like to implement something in python using b2 and its command line tool. Current implementation already lets me import it (after I symlink it to
b2.py
, that is) and call functions on it, which is good, however for any application which is not console-based or requires some resiliency against errors, it is impossible to use due to the current architecture. It is also not possible to test it automatically in isolation. Clearly the current codebase is already designed with integration with other python code - at least partially.The problem is with two layers being mixed with each other. One layer is what performs operations on the backend (let's call it controller) and the other is what displays the retrieved information (let's call it view). For example, if I would like to create a GUI application which would present the result of
ls
, I can't, because the function usesprint
to return results to the user. Here the layers should be divided so that the backend function returns an iterator of entries (objects), which would then be printed by the view function. If someone would need to call a library equivalent ofls
, he would call the backend one and then display the result in the GUI (or web page or whatever he is trying to build).Another example is that if something does not exist or there is some other problem, current tool calls
sys.exit()
. If the user supplies invalid data to the gui application, as an application developer I want to display an error message, not shutdown the whole program. Therefore I'd expect the library functions to raise an exception on error, so that it can be handled properly.It is possible to implement most of the functionality of b2 command line tool again in a way which has properly separated layers and allows for console, gui, web page and other types of outputs, as well as for automated testing in isolation.
On the other hand, the same changes could be developed here in this repository, with keeping most of the interface as it is. To be precise, I'd contribute most (if not all) of the code and tests required to do this properly. As it is a larger amount of work, I'd like to discuss it first here, so if my view and views of official maintainers are not aligned, it can be compared before much work is put into development.
Please comment the above.
The text was updated successfully, but these errors were encountered: