search

anaconda-graveyard / nb_anacondacloud

Interact with Anaconda Cloud
BSD 2-Clause "Simplified" License
5 stars 9 forks source link

rename to nb_publish, add other upstream options #14

Open bollwyvl opened 8 years ago

bollwyvl commented 8 years ago

As discussed in stand-up: nb_anacondacloud is not a good name, as we might do something else with it later. It's also long. And this package would work with your local/on-premises anaconda as well, not just cloud.

Further, the activity of publishing to the The Cloud is not specific to Anaconda Cloud.

If our target is adoption, we should allow for publishing to, at the very least, GitHub gists (which are well supported by nbviewer, etc.) while at the same time leaving hooks for easy extension by other providers.

Thus, we might end up with nb_publish_anacondacloud, nb_publish_gist, etc. as plugins to nb_publish, with each having the ability to provide UI and routes.

malev commented 8 years ago

@bollwyvl what about having one extension publishing to many providers:

fwiw I like nb_publish

bollwyvl commented 8 years ago

what about having one extension publishing to many providers

That's fine, too: it's just a matter of how many provider tool chains it will entail: anaconda-client isn't exactly nothing. I don't know what the "base" one would be, as the degenerate case of "file" is already handled. Perhaps an HTTP post?

malev commented 8 years ago

too much hassle, I'm also fine with nb_publish_anacondacloud nb_publish_gist seems easy (there is already an example)

damianavila commented 8 years ago

:+1: to nb_publish. I also like a plugin-based structure...