swagger compliance about py2cytoscape HOT 7 CLOSED

Hi, Jorge – It’s a pretty good topic. If you knew that 40 different apps were to have their own Python and R interfaces, what would you do? We definitely don’t want to be on the hook for creating those interfaces … either the app author or someone who cares about the app will. And they’ll need to be maintained as the app evolves. From the workflow author perspective, it’s counterproductive to make him/her wade through interfaces for a bunch of apps he/she isn’t interested in. So, this argues for the individual modules to be available through appropriate clearinghouses. It’s natural for Python programmers to go to PyPI … and maybe the Cytoscape App store, too. Maybe both. It’s also irritating for a Python programmer to be looking for an app interface and not finding it in short order. That orders for presence in py2cytoscape itself. Given that, we’re looking for a balance. Clearly, interfaces to core apps can be in py2cytoscape. After that, it should be very easy for workflow authors to discover other interfaces. What do you think?? … this is definitely timely. From: Jorge Boucas [mailto:[email protected]] Sent: Tuesday, February 20, 2018 11:24 AM To: cytoscape/py2cytoscape <[email protected]> Cc: Barry Demchak <[email protected]>; Assign <[email protected]> Subject: Re: [cytoscape/py2cytoscape] swagger compliance (#53) that is definitely a good point. We should reflect a bit on this: * A) would we then push towards a self contained packaged (with py2cytoscape as dependency) for every non core app? In this case we can use the String App as a show case. * B) otherwise we could have it like for core Apps. i.e. cyrest/string.py with the respective class and functions inside and then something like a def string() in the cyclient class in cyrest/cyrest.py. Given it would stay fixed to one contained file cyrest/string.py and a section in cyrest/cyrest.py it would still be easy to both develop and deprecate when required. For option B it would be important to make sure Apps are enclosed as described for the String App. On the long run B would clearly demand more work from a package maintenance side but also make the package more complete and probably enforce proper and continuous maintenance of all the python interface for non-core apps. I would vote for B but I am probably biased as that was my initial intention. (ps. I added the link to the table which I initially forgot - sorry for that) — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#53 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/ADhl3k20hMWRffkPywkp56bfP2h6gRPGks5tWxvFgaJpZM4SJwtY> . <https://github.com/notifications/beacon/ADhl3piehh6uDrwNNE_QNygni1y19QI7ks5tWxvFgaJpZM4SJwtY.gif>