From: Guignon, V. (Bioversity-France) <v.g...@cg...> - 2018-09-21 16:35:59
|
In my case 5pm (France time) is ok. Val From: Stephen Ficklin [mailto:spf...@gm...] Sent: vendredi 21 septembre 2018 17:57 To: gmo...@li... Subject: Re: [Gmod-tripal] Tripal & Python Hi Anthony, I think the answers to your questions would best be addressed in a meeting with multiple participants because some of those questions don't yet have answers. The biggest item is that we do not want to lose the entity/field design of Tripal v3 which allows for cross-site querying. Also, just by way of information, the Tripal loaders are slow but can be improved. For example, loading the Gene Ontology using Tripal's OBO loader used to take 6-8 hours. In the most recent development version it only takes 30-45 minutes to load GO (10 minutes to actually load GO and 20-30 for populating the cvtermpath table). Also, the loader can load some of the newer ontologies that have borrowed terms from other vocabularies, so it's much more robust now. I'm sure we can improve performance of other loaders as well, especially as we move towards a middle-layer Tripal library. Unfortunately time zones don't help with getting everyone together for a meeting. Our current Tripal User's Meeting is at 8am US Pacific time and 5pm Central European time. But typically those in Europe are not attending because I suspect of the late time of the day in Europe and our meeting typically occurs on a Friday. If we shift it one direction or the other it makes it difficult for folks to be there on either continent. We'd like to have you included in the discussions. I'm wondering, and this question is for everyone interested in participating. If we have a meeting regarding Tripal and Python at 5pm Central European/8am US Pacific Time can those in Europe make the call? Could folks do a 4pm Central European/7am US Pacific Meeting? I think if we go to 6am US Pacific that will be too early and 6pm Central European will be to late. I think folks in-between are probably okay either way. Thoughts? Stephen On 9/19/2018 9:07 AM, Anthony Bretaudeau wrote: Hi, Thanks for the clarification, no problem to make a demo whenever you like! At the moment, the main features of both python-chado and python-tripal are to load data (fasta/gff/blast/interproscan/blast2go/orthology/expression). Python-tripal calls Tripal webservices to do it, Python-chado do it directly by making SQL queries on the chado db. So I think what you'd like to do for Tripal 4 is closer to python-chado? What is not clear yet for me is : - what exactly would you like to be implemented in this tripal4-python library? Doing the data loading outside of tripal is easy (well), but I guess templates for example would need to remain in the php code? Field definitions (like https://tripal.readthedocs.io/en/latest/dev_guide/custom_field/manual_field_creation.html) or entities probably too? This is linked to the second point: - how you would make the tripal 4 php code communicate with this tripal-python library? For data loading, it's just writing one time the db with python, then reading the db from php anytime. I have no idea if calling python code is possible/advicable if field or entity definition is coded in python for example... I think example of codes that you would like to move to python would help me understand better the whole idea. Maybe these are stupid questions as I'm not very up to date on the latest Tripal 4 plans and Drupal 8 features. (Let me know if you prefer to continue discussing in the github issue) Anthony Le 18/09/2018 à 19:00, Lacey Sanderson a écrit : Hi Anthony, Thank you for reaching out! The modules you linked to are actually part of the motivation of this proposition and we definitely want to build on the lessons learned during their development. The python library proposed is a “pilot” project to re-write the non-Drupal components of Tripal into a standalone Tripal library that would be released as Tripal 4. This would be a re-write, not a plug-in of the current Tripal 3. What remains after removing all the non-Drupal-specific code would be a much slimmed down "Tripal Drupal" module. Stephen has made an awesome schematic showing the difference between Tripal 3 and the proposed Tripal4 here: https://github.com/tripal/tripal/issues/636#issuecomment-422463648 In my mind the benifits of switching to python for the core Tripal library is that it would allow your modules to interact with Tripal directly rather then through web services. It would also make it easier for yourself and other python developers to customize a Drupal/Tripal site without needing to learn PHP or deal with the steep learning curve of Drupal. The intent is to use a python class-based approach to make extending the implementation of an entity (e.g. gene) and/or field (e.g. unique identifier) a simple matter of extending the correct class. The same goes for chado data loaders, installers, etc. So to summarize, there are many reasons we are considering python for the core Tripal library: - Abstract customizing a Tripal/Drupal site from the Drupal logic to protect our users from the Drupal release cycle - To facilitate interaction with Tripal to/from python programs (your modules already cover this) - Allow python developers to extend a Tripal/Drupal site without needing to learn PHP/Drupal - Allow Tripal to be used without Drupal, either as a library for interacting with Chado or to feed a different CMS We would greatly appretiate the participation of your group in this feasibility study! I think a great second meeting of the group would be a demo of your modules so we can see all the capability that already exists -if you are willing and have time of course. Regardless, we have already started to look closely at these modules. ~Lacey On September 18, 2018 at 3:48:44 AM, Anthony Bretaudeau (ant...@in...<mailto:ant...@in...>) wrote: Hi, I'm a little confused, from what I understand, it looks a lot like what we (Helena Rasche, me and now Matéo Boudet) have been working on during the last years: * python-tripal (https://github.com/galaxy-genome-annotation/python-tripal/) to load/query data to/from a Tripal instance * python-chado (https://github.com/galaxy-genome-annotation/python-chado/) to load/query data to/from a Chado database (Tripal or not). * chado-schema-builder (https://github.com/erasche/chado-schema-builder/) to prepare pre-loaded, ready-to-use Chado SQL dumps. So I think building on these bases would be much easier than starting something from scratch and reinventing the wheel... Of course contributions and feature requests are warmly welcome for all these projects. I'd be happy to discuss it in a meeting if there's interest (french timezone). Cheers Anthony Bretaudeau BIPAA/GenOuest, Rennes, France Le 17/09/2018 à 18:00, Stephen Ficklin a écrit : Hi All, In our recent Tripal User's meeting we spoke about several issues related to longevity and flexibility of Tripal. One of the decisions from this meeting was to work towards separation of components of Tripal that are not specific to Drupal so that others who would prefer to not use Drupal can take advantage of the infrastructure that Tripal provides. These non-Drupal components (such as Chado installers, data loaders, entities and fields) will form a new Tripal library which can be used by the Tripal Drupal module or by others who decide not to use Drupal. One suggestion that was put forth was to perform a feasibility study to see if a Python implementation of this new Tripal library could work. Python was selected because if of its broad use in informatics and data analytics. To be clear, this does not mean that Tripal will be abandoning Drupal or PHP. If the feasibility study demonstrates difficulty integrating with Drupal or not-enough interest from our community then we will explore a PHP-based Tripal core library instead. We are reaching out to the community to solicit volunteers to help with this initial feasibility project. We'd like to have a kick off meeting for the Python implementation in the next few weeks. If you are interested in participating can you please send me an email as well as your time zone so we can coordinate a meeting time. Thanks! Stephen _______________________________________________ Gmod-tripal mailing list Gmo...@li...<mailto:Gmo...@li...> https://lists.sourceforge.net/lists/listinfo/gmod-tripal _______________________________________________ Gmod-tripal mailing list Gmo...@li...<mailto:Gmo...@li...> https://lists.sourceforge.net/lists/listinfo/gmod-tripal _______________________________________________ Gmod-tripal mailing list Gmo...@li...<mailto:Gmo...@li...> https://lists.sourceforge.net/lists/listinfo/gmod-tripal |