Backbone interop

[lidavidm]

Anaconda Launcher and Conda UI both use Backbone to structure their app; presumably Wakari Express is going to go down this route as well.

Backbone is designed to use AJAX to fetch data from REST APIs. conda-js is structured more like RPC. Would it be useful to include Backbone collections/models in conda-js (or an optional support library) to resolve this mismatch?

• Implement REST API
• Implement Python REST server
• Make conda-js work with multiple remote servers simultaneously
• Write Backbone interop collections/models
• Do we want full Backbone compatibility, or are we planning on making direct API calls in most cases?
• Testing

EDIT: not sure how much value Backbone interop would have for us. As written, conda-ui and anaconda-launcher mostly make API calls directly and use Backbone.Collection/Model mostly to pull data from the server, not to update it, and so all we need is a few sync methods.

[lidavidm]

I suppose @mattpap and @tswicegood would be most interested in this.

[tswicegood]

@lidavidm is there a way to make to make a RESTful api to the actual environments and packages? I can think of a quite logical layout:

/envs/
/pkgs/
/envs/{{ some environment }}/
/envs/{{ some env }}/{{ some package }}/
/pkgs/{{ some package }}/{{ some version }}/

[lidavidm]

Sure, but then the server would have to parse that URL structure and turn it back into a command list - this would have to be duplicated for each app or put into a separate library. The idea behind just sending the command list is to minimize the burden on the server implementation.

[lidavidm]

FWIW that's basically the structure conda-ui has at the moment.

[lidavidm]

Also, the JS API itself is structured that way already (an Env object, a Package object, etc.) Perhaps we could figure out a way tag each method with a URL and generate at least the code to map between URL and API call/command list.

[tswicegood]

@lidavidm the long term goal would be to have the server component externalized into a conda-agent repository. Then you would install it via conda install conda-agent and run it via conda agent --daemon or some such so the server piece would just be part of one server.

As for generating the URLs, I think we can come up with a basic structure to parse for installation and removal. For example,

• POST /envs/sample/ <-- creates a new environment called sample
• GET /envs/sample/ <-- any information we know
• POST /envs/sample/conda-api/ <-- installs new package with option payload for version info
• PUT /envs/sample/conda-api/ <-- updates package to new version

That doesn't help with commands like info, but I think we can handle that by adding a catch all so commands would work like this:

• GET /info/?system
• GET /config/?get=channels
• GET /list/?q=redis (using q as a generic "query" object like a lot of search indexes do)
• GET /list/?q=py$

Thoughts?

[lidavidm]

Alright, so we map /api/{method}/?args to conda {method}. For the args dict, we map the contents of q to positional arguments, keys to a flag, and key values to the flag argument. And we write a little code to map /api/envs.

But for Launcher/any other serverless app, we would still need some sort of Backbone interop, right?

[tswicegood]

Yes. We'll need to basically be able to pivot at request to fill the Backbone model with data from either the REST API or the actual Node-based API.

[lidavidm]

a174464 and 23df45a add a RESTful mode to the client.

> (new conda.Env('test', '/test')).install({ packages: ['python'] })
POST http://localhost:8000/api/env/prefix/%2Ftest/python
> (new conda.Env('test', '/test')).remove({ packages: ['python'] })
DELETE http://localhost:8000/api/env/prefix/%2Ftest/python
> conda.search()
GET http://localhost:8000/api/search
> conda.search({ regex: 'ipython' })
GET http://localhost:8000/api/search?q%5B%5D=test

EDIT: https://github.com/conda/conda-js/tree/master/agent now contains sample servers (flask Blueprints that can be included in other applications), and this library has been updated with a full RESTful mode.